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Abstract 


This  is  a  demonstration  project  to  illustrate  the  benefits  of  task  network  modelling  as  a  means  of 
quantifying  future  changes  to  system  design  or  operational  concepts  prior  to  the  build  stage  or 
system  implementation.  The  specific  task  environment  selected  for  the  demonstration  is  the 
process  of  analysing  narrow  band  sonar  data  to  detect  and  identify  sonar  targets,  which  are  key 
tasks  in  building  the  Underwater  Maritime  Picture.  Function  and  critical  task  analysis  of  existing 
sonar  analysis  practices  were  conducted  to  generate  appropriate  functions  and  tasks  to  be  modelled. 
The  Integrated  Performance  Modelling  Environment  (IPME)  software  was  used  to  build  a  task 
network  model,  the  essential  components  of  which  were  validated  by  an  experienced  Navy  sonar 
subject  matter  expert.  The  model  was  then  used  to  assess  the  effects  of  semi-automating  the 
critical  process  of  sanitising  ownship  and  Task  Group  sonar  data  from  the  display,  by  comparing 
system  performance  for  baseline  (manual)  and  automated  conditions.  Results  showed  a 
performance  increase  for  the  automated  of  approximately  30%  in  terms  of  contacts  identified.  This 
performance  gain  was  achieved  with  no  costs  to  operator  workload.  The  prototype  system 
developed  provides  core  functionality  to  explore  future  “what-if  ’  questions  with  respect  to  the 
redesign  of  sonar  systems  and  their  concept  of  operations. 
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Resume 


II  s'agit  d'un  projet  de  demonstration  qui  vise  a  montrer  les  avantages  de  la  modelisation  d'un 
reseau  de  taches  comme  moyen  de  quantifier  les  fiiturs  changements  a  apporter  a  la  conception  de 
systemes  ou  a  leurs  concepts  operationnels  avant  la  construction  ou  la  mise  en  oeuvre  des  systemes. 
Ce  qu'on  a  retenu  comme  conditions  d'execution  des  taches  particulieres  aux  fins  de  la 
demonstration,  c'est  le  processus  d'analyse  des  donnees  obtenues  par  sonar  a  bande  etroite  pour  la 
detection  et  l'identification  des  cibles  sonar,  qui  regroupe  des  taches-cles  de  l'etablissement  de  la 
situation  maritime  sous-marine.  L'analyse  de  taches  critiques  et  de  fonctions  a  ete  appliquee  aux 
pratiques  d'analyse  de  donnees  sonar  en  place  pour  generer  les  taches  et  les  fonctions  appropriees  a 
modeliser.  Le  logiciel  d'environnement  integre  de  modelisation  de  la  performance  (IPME)  a  ete 
utilise  pour  la  mise  au  point  d'un  modele  de  reseau  de  taches,  dont  les  elements  essentiels  ont  ete 
valides  par  un  expert  chevronne  du  sonar  de  la  Marine.  Le  modele  a  ensuite  servi  a  1'evaluation  des 
effets  de  la  semi-automatisation  du  processus  critique  d'epuration  des  donnees  sonar  de  son  propre 
navire  et  du  groupe  operationnel  de  l'affichage,  par  une  comparaison  du  rendement  des  systemes 
entre  un  modele  de  reference  (manuel)  et  des  conditions  automatisees.  Les  resultats  ont  fait 
ressortir,  dans  le  cas  des  conditions  automatisees,  une  amelioration  du  rendement  d'environ  30  % 
en  ce  qui  conceme  les  contacts  identifies.  Ce  gain  de  rendement  a  ete  realise  sans  accroissement  de 
la  charge  de  travail  de  l'operateur.  Le  prototype  elabore  assure  les  fonctions  de  base  pour  explorer 
les  futures  questions  hypothetiques  en  ce  qui  concerne  le  remaniement  des  systemes  sonar  et  leur 
concept  d'operation. 
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Executive  Summary 


The  task  of  building  the  underwater  maritime  picture  depends  heavily  on  the  accurate  and  timely 
analysis  of  sonar  acoustic  data  that  may  be  highly  uncertain  in  origin  and  embedded  in  background 
“noise”  from  a  variety  of  underwater  acoustic  sources.  The  task  of  distinguishing  signal  from  noise 
and  recognising  combinations  of  signals  as  representative  of  a  particular  contact  signature  falls 
upon  the  sonar  operator.  Previous  function  and  task  analyses  of  passive  and  active  sonar  systems 
have  identified  the  critical  tasks  performed  by  operators  in  identifying  contacts  of  interests.  While 
the  time  course  of  many  contacts  is  sufficiently  slow,  which,  in  itself,  does  not  produce  time  stress 
upon  operators,  the  large  volume  of  acoustic  data  presents  a  continuing  task  of  detection  and 
analysis  that  can  be  overwhelming  for  operators  to  deal  with.  In  particular,  acoustic  data  generated 
from  ownship  and  adjacent  members  of  a  task  group  may  swamp  the  acoustic  analysis  system  with 
multiple  instances  of  data  that  must  be  sifted  through  and  logged  (sanitised),  in  order  to  allow  a 
better  picture  to  emerge  of  the  primary  acoustic  contacts  of  interest.  Thus,  there  is  a  continuing 
interest  by  researchers  in  methods  to  improve  the  effectiveness  of  the  analysis  process  by 
automating  certain  operator-intensive  functions  that  may  require  repeated,  low-level  cognitive 
analysis.  This  would  free  up  operators  to  perform  the  more  complex  and  critical  tasks  of  analysing 
contact  signatures  and  classifying  sources. 

The  present  project  is  a  demonstration  of  how  automation  issues  in  the  analysis  of  sonar  data  can 
be  addressed  a  priori,  by  building  a  network  model  that  simulates  the  operator’s  role.  By 
constructing  a  baseline  model  of  a  generic  sonar  detection  and  analysis  process  and  measuring  its 
performance  capabilities,  we  can  then  ask  questions  concerning  how  hypothetical  decision-aids  or 
methods  of  automation  may  improve  upon  baseline  performance. 

A  network  model  of  a  generic  sonar  detection  task  (based  largely  upon  CANTASS)  was 
constructed  using  information  from  prior  function  and  task  analyses  and  with  input  from  an 
experienced  Navy  sonar  instructor.  The  model  comprised  a  two-operator  suite,  a  processing 
environment  that  involved  multiple  beams  of  sonar  data  in  the  form  of  simulated  frequency-time- 
intensity  displays,  with  the  overall  goal  that  operators  identify  and  log  all  sonar  data  that  were 
“present”.  The  model  ran  for  an  approximation  of  a  Navy  watch,  approximately  eight  hours, 
during  which  time  approximately  3000  lines  of  sonar  data  were  generated  for  analysis.  Some  of 
the  lines  represented  acoustic  noise  of  no  interest,  other  lines  represent  unknown  targets,  while 
other  lines  represented  signatures  (combinations  of  lines)  of  contacts  of  interest.  System 
performance  was  measured  in  terms  of  the  number  of  contacts  logged,  the  number  of  times  the  task 
group  data  were  sanitised  and  the  number  of  lines  missed.  Operator  performance  was  assessed  in 
terms  of  workload  for  vision,  cognitive,  auditory  and  psychomotor  modalities. 

To  assess  the  effects  of  automation  on  system  performance,  a  semi-automated  decision  aid  was 
modelled  which  enabled  the  operator  to  more  quickly  detect,  recognise  and  classify  acoustic  data 
coming  from  ownship  or  the  task  group. 

A  comparison  between  baseline  and  automated  conditions  showed  a  gain  of  approximately  30%  in 
the  automated  condition  for  the  number  of  lines  logged  and  an  eightfold  increase  in  the  number  of 
times  the  data  were  sanitised.  These  performance  improvements  were  obtained  with  no  significant 
effects  on  operator  workload. 

Thus,  the  project  has  demonstrated  that  a  modelling  approach  using  task  network  simulation  may 
be  used  to  address  a  variety  of  “what- if’  questions  concerning  sonar  system  re-design  and/or 
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personnel  and  role  re-assignment,  and  to  obtain  answers  to  such  questions  that  are  quantitative  in 
nature,  and  which  address  operationally  relevant  system  goals.  The  approach  is  recommended  for 
identifying  critical  areas  for  the  selection  of  decision  aids  and  automated  functions  in  future  system 
re-design,  to  ensure  that  the  maximum  benefit  to  the  operator  is  obtained  in  terms  of  performance 
effectiveness  and  workload  maintenance. 
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Sommaire 


La  tache  d'etablir  la  situation  maritime  sous-marine  depend  fortement  de  l'analyse  precise,  en  temps 
opportun,  de  donnees  acoustiques  sonar  dont  l'origine  peut  etre  tres  incertaine  et  qui  peuvent  etre 
integrees  au  «  bruit  »  de  fond  en  provenance  de  diverses  sources  acoustiques  sous-marines.  La 
tache  de  distinguer  le  signal  du  bruit  et  de  reconnaitre  des  combinaisons  de  signaux  comme 
elements  representatifs  de  la  signature  particuliere  d'un  contact  donne  incombe  souvent  a 
l'operateur  sonar.  Des  analyses  anterieures  des  fonctions  et  des  taches  de  systemes  sonars  passifs  et 
actifs  ont  permis  d'identifier  les  taches  critiques  que  l'operateur  execute  dans  l'identification  des 
contacts  presentant  de  l'interet.  Meme  si  de  nombreux  contacts  ont  une  progression  suffisamment 
lente,  ce  qui,  en  soi,  ne  produit  pas  de  stress  lie  au  temps  pour  l'operateur,  la  grande  quantite  de 
donnees  acoustiques  occasionne  une  tache  continue  de  detection  et  d'analyse  qui  peut  s'averer 
accablante  pour  l'operateur.  En  particulier,  les  donnees  acoustiques  generees  par  son  propre  navire 
et  des  membres  adjacents  du  groupe  operationnel  risquent  de  submerger  le  systeme  d'analyse 
acoustique  par  de  multiples  donnees  qu'il  faut  passer  en  revue  et  consigner  (epurer)  pour  permettre 
d'obtenir  une  meilleure  situation  a  partir  des  contacts  acoustiques  primaires  presentant  de  l'interet. 
Ainsi,  les  chercheurs  portent  un  interet  soutenu  aux  methodes  qui  permettraient  d'ameliorer 
l'efficacite  de  l'analyse  grace  a  l'automatisation  de  certaines  fonctions  qui  exigent  beaucoup  de 
l'operateur,  du  fait  qu'elles  peuvent  demander  une  analyse  cognitive  de  faible  niveau  a  repetition. 
Cela  permettrait  de  liberer  l'operateur,  qui  pourrait  alors  effectuer  les  taches  plus  complexes  et 
critiques  d'analyse  des  signatures  des  contacts  et  de  classification  des  sources. 

Le  present  projet  est  une  demonstration  de  la  fa9on  dont  on  peut  aborder,  a  priori,  les  questions 
d'automatisation  dans  l'analyse  des  donnees  sonar,  en  elaborant  un  modele  informatique  qui  simule 
le  role  de  l'operateur.  En  mettant  au  point  un  modele  de  reference  d'un  processus  generique  de 
detection  et  d'analyse  au  moyen  d'un  sonar  et  en  mesurant  ses  capacites  de  rendement,  nous 
pouvons  alors  poser  des  questions  sur  la  fa?on  dont  d'hypothetiques  methodes  d'automatisation  ou 
aides  a  la  decision  permettraient  d'ameliorer  le  rendement  de  base. 

Un  modele  en  reseau  d'une  tache  generique  de  detection  sonar  (fonde  largement  sur  le  systeme 
CANTASS)  a  ete  mis  au  point  au  moyen  de  l'information  obtenue  a  partir  d'analyses  anterieures  de 
taches  et  de  fonctions  et  avec  la  contribution  d'un  instructeur  chevronne  de  la  Marine  pour 
l'utilisation  du  sonar.  Le  modele  se  composait  d'une  suite  pour  deux  operateurs,  un  cadre  de 
traitement  qui  comporte  de  multiples  faisceaux  de  donnees  sonar  sous  la  forme  d'affichages 
frequence-temps-intensite  simules,  dans  le  but  general  de  permettre  a  l'operateur  d'identifier  et  de 
consigner  toutes  les  donnees  sonar  qui  etaient «  presentes  ».  Le  modele  a  toume  pour  une 
approximation  d'un  quart  de  la  Marine,  d'une  duree  d'environ  huit  heures,  periode  au  cours  de 
laquelle  environ  3  000  lignes  de  donnees  sonar  ont  ete  generees  aux  fins  d'analyse.  Certaines  lignes 
representaient  du  bruit  acoustique  sans  interet  et  d'autres  lignes,  des  cibles  inconnues,  tandis  que 
d'autres  lignes  representaient  des  signatures  (combinaisons  de  lignes)  de  contacts  presentant  de 
l'interet.  Le  rendement  du  systeme  a  ete  mesure  par  le  nombre  de  contacts  consignes,  le  nombre  de 
fois  que  les  donnees  de  groupes  operationnels  ont  ete  epurees  et  le  nombre  de  lignes  ratees.  Le 
rendement  de  l'operateur  a  ete  evalue  d'apres  la  charge  de  travail  pour  les  modalites 
psychomotrices,  auditives,  cognitives  et  visuelles. 

Afm  d'evaluer  les  effets  de  l'automatisation  sur  le  rendement  du  systeme,  une  aide  a  la  decision 
semi-automatisee  a  ete  modelisee  pour  permettre  a  l'operateur  de  detecter,  de  reconnaitre  et  de 
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classer  plus  rapidement  les  donnees  acoustiques  en  provenance  de  son  propre  navire  ou  du  groupe 
operationnel. 

Une  comparaison  entre  le  modele  de  reference  et  les  conditions  automatisees  a  fait  ressortir,  dans 
les  conditions  automatisees,  un  gain  d'environ  30  %  en  ce  qui  conceme  le  nombre  de  lignes 
consignees  et  une  multiplication  par  huit  du  nombre  de  fois  que  les  donnees  ont  ete  epurees.  Ces 
ameliorations  du  rendement  ont  ete  obtenues  sans  effet  significatif  sur  la  charge  de  travail  de 
l'operateur. 

Ainsi,  le  projet  a  montre  qu'il  est  possible  d'aborder  la  modelisation  par  la  simulation  d'un  reseau  de 
taches  pour  etudier  diverses  questions  hypothetiques  concernant  le  remaniement  des  systemes 
sonar  et/ou  la  reaffectation  des  effectifs  et  des  roles,  ainsi  que  pour  trouver  des  reponses  a  des 
questions  de  nature  quantitative  qui  portent  sur  des  objectifs  de  systemes  pertinents  sur  le  plan 
operationnel.  C'est  une  approche  qu'il  est  recommande  d'adopter  pour  identifier  les  domaines 
critiques  pour  la  selection  d'aides  a  la  decision  et  de  fonctions  automatisees  dans  le  cadre  du  fiitur 
remaniement  des  systemes,  si  Ton  veut  s'assurer  d'obtenir  des  retombees  maximales  pour 
l'operateur  en  ce  qui  conceme  l'efficacite  du  rendement  et  le  maintien  de  la  charge  de  travail. 
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1.  Background 


The  present  project  arises  from  previous  work  contracted  to  HSI  with  the  common  objective  of 
improving  the  understanding  of  human  factors  issues  in  the  processing  of  sonar  information  by 
human  operators.  The  outcomes  of  this  work  serve  both  the  scientific  community  in  its  research 
and  development  of  new  sonar  concepts,  and  the  operational  community  in  terms  of  relevance  to 
system  design  and  manning  issues.  This  program  has  been  under  the  primary  direction  of  DRDC- 
Toronto  as  the  Scientific  Authority  with  further  contribution  from  DRDC-Atlantic.  The  program 
has  involved  a  wide  range  of  studies,  as  follows: 

•  An  examination  of  design  issues  in  the  human-computer-interface  for  sonar  systems; 
operator  performance  in  a  simulated  passive  sonar  search  and  classification  task 
(Matthews,  Greenley  and  Webb,  1991) 

•  A  revision  to,  and  upgrade  of,  a  function  analysis  of  CANTASS  (Matthews,  Webb  and 
Woods,  2001) 

•  A  function  analysis  of  ANS  510  active  sonar  (Matthews  and  Webb,  2001) 

•  A  function  analysis  of  TIAPS  and  review  of  implications  for  HCI  design  (Matthews, 
Webb  and  Woods,  2001) 

A  number  of  recommendations  arising  from  the  latter  report  have  provided  the  basis  for  the 
direction  for  the  current  project.  These  have  stemmed  from  an  interest  in  how  emerging  ideas  and 
concepts  of  automated  sonar  information  processing  will  impact  upon  the  human  operators  of  sonar 
systems.  Such  impacts  may  have  implications  for  system  design,  function  allocation  between  the 
system  and  operators  -  as  well  as  between  operators,  manpower  levels,  operational  procedures  and 
training.  Of  particular  interest  is  how  automation  will  directly  change  the  way  operators  perform 
critical  tasks  of  search  and  identification,  and  whether  system  performance  can  be  successfully 
modelled  using  a  network  simulation  approach.  Such  modelling  would  provide  an  invaluable  tool 
for  assessing  a  priori  the  impact  of  different  system  design  alternatives  on  operator  performance 
and  workload.  A  model  of  a  sonar  system  would  allow,  for  example,  each  of  the  following  system 
concepts  to  be  simulated  and  the  change  in  system  performance  from  baseline  to  be  quantitatively 
and  qualitatively  assessed: 

•  The  impact  of  increasing  the  number  of  sensor  beams  from  44  to  1 00 

•  The  maximum  number  of  sensor  beams  that  a  single  operator  can  handle  before  search 
and/or  identification  processes  degrade 

•  The  additional  human- operator  capacity  that  might  be  achieved  through  a  system  that 
automatically  detected  and  identified  known  target  lines  (e.g.  equivalent  to  the  operator 
intensive  task  of  sanitising  the  passive  array) 

•  The  increased  capacity  that  could  be  created  by  an  automated  function  that  deals  with 
lines  that  are  easy  to  detect  and  identify,  thereby  freeing  the  operator  to  focus  on  more 
complex  detections  and  identifications 

•  The  impact  of  a  tactical  representation  of  automatically  generated  sonar  data  upon  the 
functions  and  tasks  performed  by  the  operator(s)  and  how  the  system  would  perform 
compared  with  baseline 
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Clearly,  there  is  a  broad  range  of  practical  and  useful  outcomes  from  such  an  analysis  and 
modelling  process.  The  following  section  deals  with  the  specific  goals  and  objectives  of  the 
current  project. 
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2.  Goals  and  Objectives 


The  overarching  and  general  goal  is  to  develop  a  demonstration  product  to  show  the  utility  of 
function  analysis,  task  modelling  and  network  simulation  for  assessing  design  alternatives  and 
function  automation  on  operator-system  performance  in  the  processing  of  sonar  information.  Since 
function  analysis  of  a  number  of  specific  sonar  systems  has  already  been  accomplished  in  previous 
work,  the  current  focus  is  on  task  modelling  through  network  simulation. 

In  agreement  with  the  SA,  the  following  objectives  were  identified: 

1 .  Develop  a  generic  sonar  function  flow  model  and  identify  potential  functions  that 
could  be  automated. 

2.  Within  the  generic  model  select  a  critical,  core  function  for  more  detailed  analysis  and 
modelling. 

3.  Create  a  baseline  task  network  simulation  of  the  selected  function. 

4.  Evaluate  the  impact  of  a  specific,  automated  function  on  the  performance  of  the  system 
in  comparison  with  the  baseline 

5.  Analyse  the  impact  of  such  automation  on  the  baseline  operator’s  tasks  and  mental 
models. 

6.  Make  recommendations  for  future  work  to  expand  the  model  to  evaluate  more  complex 
forms  of  automation  and  alternate  system  designs. 

In  order  to  achieve  the  above,  a  number  of  constraints,  limitations  and  assumptions  have  needed  to 
be  made  in  order  to  focus  the  project  in  a  direction  that  will  provide  the  maximum  payoff  for  the 
resources  available.  These  factors  are  addressed  in  the  section  four.  Before  discussing  these 
issues,  however,  we  think  it  useful  to  review  some  basic  concepts  and  definitions. 
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3.  Basic  concepts  and  definitions 


3.1  Function  analysis 

This  technique  involves  the  identification  of  the  key  functions  and  their  interrelationships  that  are 
required  to  achieve  system  objectives.  Functions  represent  high-level  descriptions  of  logical  units 
of  behaviour  of  a  system  that  must  be  performed,  rather  than  describing  the  engineering  or  human 
sub-systems  that  actually  implement  the  functions.  Function  analysis  consists  of  a  hierarchical 
analysis  and  description  that  starts  at  the  upper  levels  and  progresses  to  lower  levels  of 
decomposition.  Typically,  the  stopping  point  of  the  decomposition  is  at  the  level  of  specific  task 
descriptions  to  be  performed  by  individual  operators,  hardware  or  software. 

In  the  function  analyses  already  conducted  of  sonar  systems  the  primary  output  has  been  function 
descriptions  and  function  flow  diagrams.  Function  flow  diagrams  represent  graphically  the 
sequential  functions  required  to  accomplish  mission  objectives.  The  flow  sequence  of  the  diagrams 
represents  the  order  in  which  functions  are  performed,  using  AND/OR  logic  to  indicate  parallel  or 
serial  processes.  Each  function  is  numbered  in  a  logical  manner  to  indicate  its  relationship  in  the 
hierarchy.  Note  that  in  the  work  accomplished  to  date,  the  SA  directed  that  the  function  analyses  be 
stopped  short  of  the  level  of  the  individual  operator  tasks. 

Function  description  contain  the  following  components: 

1.  Name  of  Function 

2.  Missions  Under  Which  Function  Occurs 

3.  System  Units  Which  Support  Function 

4.  Super-ordinate  Functions 

5.  Sequential  Categorisation  of  Functions 

6.  Estimate  of  Criticality  of  Function 

7.  Critical  Variables  (e.g.  own  ship  speed,  own  ship  manoeuvres,  oceanographic 
conditions) 

8.  Required  Quality  of  Output  for  Function 

9.  Estimate  of  Probability  of  Failure  to  Complete  A  Function 

10.  Consequences  of  Failure  to  Complete  A  Function 

11.  Estimate  of  Time  to  Completion 

12.  Sub-functions  Or  Tasks 

13.  Sequencing  of  Sub-functions  or  Tasks 

14.  Allocation  of  Function  to  Man,  Software  or  Hardware 

15.  Interdependency  Of  Functions 

One  limitation  of  function  analysis  is  that  it  does  not  show  the  flow  of  information  nor  the  critical 
decisions  that  need  to  be  made  in  order  to  achieve  the  function.  Thus,  the  analysis  needs  to  be 
supplemented  by  an  information  flow  and  processing  analysis  to  provide  the  level  of  details  that 
will  be  required  to  model  a  system. 

3.2  Information  flow  and  processing  analysis 

This  technique  is  also  sometimes  call  information  flow  and  decision/action  diagrams. 
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This  represents  a  more  detailed  composition  of  a  function  in  terms  of  the  specific  decisions  and 
task  sequences  that  an  operator  must  perform  to  achieve  the  function  goals.  Typically  the  analysis 
is  represented  as  information  flow  through  certain  decision  and  choice  points.  The  flow  represents 
the  serial  actions  that  are  performed  and  the  consequent  routing  of  information  to  subsequent  tasks 
based  upon  the  decision  outcome. 

3.3  Discrete  event  simulation 

This  may  also  be  referred  to  as  "task  network  modelling"  and  comprises  a  flow  chart  approach  to 
representing  decisions  and  actions  that  are  performed  over  time  as  an  integral  part  of  a  system.  The 
specific  software  employed  for  the  present  project  (Integrated  Performance  Modelling 
Environment- IPME)  uses  an  underlying  discrete  event  Monte-Carlo  simulation  engine  to  build  a 
computer  model  and  database  of  the  task  environment.  A  computer  model  of  the  process  allows 
answers  to  "what  if'  questions.  What  if  we  change  the  way  humans  work  with  the  system?  What  if 
we  change  the  tasks  done  by  humans  and  software?  What  if  we  rearrange  the  process? 

The  key  functions  of  IPME  that  will  be  used  in  this  project  include: 

Environment  Model:  The  analyst  can  model  environmental  factors  or  what  behavioural  scientists 
refer  to  as  performance  shaping  factors.  These  include  environmental  variables  such  as 
temperature,  humidity,  time  of  day,  etc. 

Operator  Characteristics:  Operator  Traits  and  States  may  be  simulated.  Traits  are  variables  such 
as  mental  ability,  susceptibility  to  motion  sickness,  time  since  trained,  etc.  States  are  variables 
such  as  fatigue,  hunger,  etc.  The  Operator  State  is  dynamically  updated  during  a  simulation. 
Therefore,  each  operator  in  the  simulation  can  have  unique  characteristics. 

Performance  Shaping  Functions:  Performance  Shaping  Functions  (PSFs)  are  user-defined 
functions  which  dynamically  modify  individual  operator  task  "Time  to  Perform"  and  "Probability 
of  Failure"  values.  PSFs  define  how  performance  shaping  factors  (environment  variables  or 
operator  characteristics)  affect  operator  performance.  PSFs  are  linked  to  individual  tasks  through  a 
task  taxonomy  allowing  one  PSF  function  to  be  dynamically  applied  to  any  similar  task  in  a  model. 
Since  PSFs  can  use  operator  states  as  expression  variables,  simulations  can  be  built  that  have  two 
operators  performing  the  same  task  type  with  different,  and  therefore  more  realistic,  "Time  to 
Perform"  and  "Probability  of  Failure"  values. 

Visual,  auditory,  cognitive,  psychomotor  (VACP)  and  W/Index:  the  IPME  model  allows  for 
estimates  of  operator  loadings  in  these  four  areas  and  also  calculates  an  overall  workload  index. 
VACP  is  an  attentional  demand  algorithm  based  upon  the  task  loading  for  an  operator  within  the 
four  separate  channels  and  estimates  the  demands  on  human  processing  resources.  To  achieve  a 
VACP  rating,  each  operator  task  is  rated  with  respect  to  the  weighted  task  demand  that  appears 
appropriate  for  the  specific  task  requirements  for  each  of  the  four  independent  channels.  Scales  to 
assist  the  generation  of  these  ratings  were  developed  originally  for  an  FHX  mission  function 
analysis  performed  by  Aldrich  and  others  (1984),  for  the  US  Army  Research  Institute.  The  scales 
provide  a  subjective  rating  for  various  levels  of  attentional  demand.  Additional  work  was  later 
published  by  Bierbaum,  Szabo,  and  Aldrich  (1987)  and  provided  enhanced  descriptors  and 
interval  scale  values. 

The  following  table  shows  the  rating  scales  for  exemplar  tasks  for  each  of  the  four  dimensions. 
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Ordinal  rating 
(W/Index) 

Interval 
rating  (VACP) 

Descriptor 

VISUAL 

1 

1 

Register/Detect  (Detect  Occurrence  of  Image) 

2 

3.7 

Discriminate  (Detect  Visual  Difference) 

3 

4 

Inspect/Check  (Discrete  Inspection/Static  Condition) 

4 

5 

Locate/Align  (Selective  Orientation) 

5 

5.1 

Track/Follow  (Maintain  Orientation) 

6 

5.9 

Read  (Symbol) 

7 

7 

Scan/Search/Monitor  (Continuous/Serial  Inspection,  Multiple  Conditions) 

AUDITORY 

1 

1 

Detect/Register  Sound  (Detect  Occurrence  of  Sound) 

2 

2 

Orient  to  Sound  (General  Orientation/Attention) 

3 

4.2 

Orient  to  Sound  (Selective  Orientation/Attention) 

4 

4.3 

Verify  Auditory  Feedback  (Detect  Occurrence  of  Anticipated  Sound) 

5 

4.9 

Interpret  Semantic  Content  (Speech) 

6 

6.6 

Discriminate  Sound  Characteristics  (Detect  Auditory  Differences) 

7 

7.0 

Interpret  Sound  Patterns 

COGNITIVE 

1 

1.0 

Automatic  (Simple  Association) 

2 

1.2 

Alternative  Selection 

3 

3.7 

Sign/Signal  Recognition 

4 

4.6 

Evaluation/Judgment  (Consider  single  Aspect) 

5 

5.3 

Encoding/Decoding,  Recall 

6 

6.8 

Evaluation/Judgment  (Consider  Several  Aspects) 

7 

7.0 

Estimation,  Calculation,  Conversion 

PSYCHOMOTOF 

! 

1 

1.0 

Speech 

2 

2.2 

Discrete  Actuation  (Button,  Toggle,  Trigger) 

3 

2.6 

Continuous  Adjustive  (Flight  Control,  Sensor  Control) 

4 

4.6 

Manipulative 

5 

5.8 

Discrete  Adjustive  (Rotary,  Vertical  Thumbwheel,  Lever  position) 

6 

6.5 

Symbolic  Production  (Writing) 

7 

7 

Serial  Discrete  Manipulation  (Keyboard  Entries) 

Table  1:  IPME  VACP  rating  scales  and  descriptors 

The  Workload  Index,  or  W/Index,  algorithm  is  based  on  the  Hybrid  W/Index  algorithms  developed 
by  Samo  and  Wickens  (1992)  and  measures  the  resource  demand  imposed  upon  the  operator  within 
resource  channels.  W/Index  decomposes  a  task  into  a  set  of  channels  and  establishes  weights 
representing  the  amount  of  demand  required  for  a  task  in  each  channel.  Unlike  the  traditional 
models,  W/Index  also  accommodates  interference  between  channels. 

The  W/Index  model  makes  two  calculations.  The  within  channel  contribution  sums  the  demand 
contributions  in  each  channel  as  if  there  was  no  interference.  The  between  channel  contribution 
looks  at  each  pair-wise  combination  of  active  tasks,  takes  the  within- channel  contribution  for  each 
task,  and  scales  the  values  using  the  values  in  a  conflict  matrix. 

The  channels  used  for  this  model  include  visual  perception,  auditory  perception,  verbal  cognition, 
spatial  cognition,  manual  response  and  speech  response.  Ratings  are  based  on  ordinal  categories 
(integers  from  1  to  7). 
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With  respect  to  the  Cognitive  component  of  the  scale  it  should  be  noted  that  there  is  no  specific 
rating  for  tasks  that  may  have  a  high  memory  component,  for  example,  when  an  operator  returns  to 
a  display  that  has  been  updated  since  it  was  last  inspected  (which  could  be  as  much  as  ten  minutes) 
and  needs  to  remember  what  lines  were  previously  there,  what  contacts  they  were  associated  with 
and  what  is  new  information.  Even  with  “cheat  sheets”  or  other  notations  that  an  operator  might 
make  to  assist  in  reducing  the  memory  load  for  this  task,  there  would  still  appear  to  be  a  high 
memory  demand  that  is  not  reflected  in  the  ratings  that  are  available. 

The  specific  VACP  values  chosen  for  each  task  will  be  described  later  in  this  report  as  we  go 
through  a  full  description  of  the  model. 
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4.  Constraints,  Limitations  and  Assumptions 


4.1  The  baseline  sonar  system 

A  baseline  system  is  one  that  represents  and  models  in  detail  the  essential  components  and  tasks 
required  to  analyse  sonar  data,  against  which  any  changes  in  system  design,  procedures  or  manning 
levels  may  be  directly  compared.  Clearly  there  are  a  number  of  existing  sonar  systems  that  could  be 
candidates  for  exact  modelling,  whether  the  focus  is  active,  passive  or  sonobuoy  sensors.  In 
considering  what  sort  of  system  to  be  modelled,  it  should  be  remembered  that  the  purpose  of 
creating  a  baseline  system  is  to  make  it  as  generic  as  possible,  but  sufficiently  grounded  in  existing 
system  reality  to  make  it  valid  for  comparison  purposes.  Therefore,  there  is  a  need  to  identify  the 
functions  and  attributes  that  are  more  or  less  common  to  all  systems,  whatever  the  underlying 
sensor  configuration  or  signal  processing  characteristics.  These  functions  include: 

•  Analysis  of  the  mission 

•  The  configuration  of  the  system  to  appropriate  underwater  conditions  and  potential 
contacts  of  interest 

•  The  assessment  of  the  system 

•  The  display  of  processed  sonar  data 

•  The  creation  of  the  tactical  picture-  which  requires: 

-  The  search  by  an  operator  of  such  data  for  sonar  contacts  of  interest 

-  The  interpretation  and  the  analysis  of  the  data  to  allow  formal  identification, 
classification  and  determination  of  contact  range,  speed  and  track. 

-  The  assessment  of  threats 

•  The  management  of  the  underwater  tactical  picture 

Subsidiary  tasks  to  support  these  functions  may  include  target  localisation,  motion  analysis  and  the 
correlation  of  information  across  sensor  systems  and  other  platforms.  These  primary  functions  and 
their  relationships  are  shown  in  the  function  flow  diagram  in  Figure  1,  which  has  been  derived 
from  the  previous  function  analyses  performed  on  ANS  510,  CANTASS  and  TIAPS.  Detailed 
descriptions  of  these  functions  can  be  found  in  the  relevant  reports  cited  above. 
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Figure  1 :  Function  flow  diagram  of  generic  sonar  system 

4.2  Automation  possibilities 

Across  the  broad  range  of  generic  system  functions,  a  number  of  automation  concepts  are  possible 
or  have  been  conceived  by  research  scientists.  To  provide  a  context  for  the  present  work,  a  small- 
scale  survey  was  initially  conducted  of  ongoing  automation  projects  at  DRDC  Toronto  and 
Atlantic.  The  information  was  compiled  from  interviews  with  Defence  Scientists  at  each  of  the 
above  as  well  as  from  reports  and  publications  that  were  made  available.  The  following  table 
shows  a  summary  of  the  information  obtained. 
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Sonar  function 

Automation  opportunities 

DRDC  Projects 

1.  Analyse  mission 

2.  Configure  system 

2.1.  Active  sonar 

Decision  aids  for  setting  active  transmission  parameters 

2.2.  Passive  sonar 

Decision  aids  for  array  configuration 

2.3.  SPS 

Decision  aids  for  buoy  deployment 

Generic 

Aids  for  developing  underwater  model 

3.  Assess  system 

Generic 

Operator  feedback  on  sensor  performance  to  fine  tune  sensors 

Operator  feedback  on  model  performance  to  fine  tune  model 

4.2.  Detect  contacts 

Generic-computer  aided 

Decision  aids  for  where  to  look  for  possible  contacts 

G.H. 

detection 

Decision  aids  for  what  to  look  for 

G.H. 

Improving  signal-noise  ratio  by  decluttering 

Operator  load  reduction  by  dynamically  allocating  between 
system  and  operator 

I.F.  R.K. 

Lofargrams 

Auto  line  detection 

G.H.,  S.McF. 

Neural  networks  for  classifying  transient  sounds 

I.F. 

Active  sonar 

Auto  feature  detection  to  aid  declutter 

W.R. 

Auto  echo  detection 

G.H. 

Passive  sonar 

Auto  detection  of  signals  (reduce  false  alarms) 

W.R. 

Aids  to  de-clutter  the  obvious 

W.R. 

Low  level  signal  followers 

G.H. 

SPS 

Enhancing  the  buoy  by  buoy  analysis 

J.M. 

Smart  output  summary  from  all  buoys 

J.M. 

Sensor  integration:  correlation  of  info 

TIAPS 

G.H. 

across  sensor  /radar  systems, 
platforms 

COM DAT 

B.M. 

NUWTDP 

W.R.,  B.M. 

Fusing  active/passive  data 

G.H. 

Table  2:  Opportunities  for  automation,  cross-referenced  to  generic  sonar  functions 

(continued  on  following  page) 
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Sonar  function 

Automation  opportunities 

DRDC  Projects 

4.3.1  Identify  contact 

Generic 

Decision  aids  for  target  ID-database  of  target  signatures 

Passive 

Decision  aids  for  target  ID  from  line  pattern 

G.H.,  B.McA. 

Decision  aids  for  ID  from  transients  (e.g.  subs) 

I.F. 

Active 

Decision  aids  for  target  ID 

Mines 

Side  scan  radar  for  auto  detection 

R.K. 

Human-machine  co-operative  detection 

R.K. 

Torpedo 

Auto  detection 

4.3.2  Locate  target 

Auto  location  from  airborne  sonobuoy  signal  and  multistatics 

IMPACT 

Auto  representation  of  spatial  uncertainty  (target  probability 
location) 

G.H. 

4.3.3  Determine  speed 

Auto  calculation  for  TMA 

Passive 

Localisation 

Assistant 

4.  Create  tactical  picture 

Correlation  of  information 

MSDF  integration  of  info  across  systems  (NUW) 

W.R.,  B.McA., 

B.M. 

Picture  representation 

Integrated  tactical  and  sonar  plot 

COMDAT 

Visualisation  of  oceanography 

NUW 

Information  management 

Reduce  info  load  on  operators/improve  information  integration 
across  systems 

SIMS 

5.  Manage  tactical  picture 

Auto  track  followers 

S.McF. 

Auto  track  deletion 

Table  2:  Opportunities  for  automation,  cross-referenced  to  generic  sonar  functions 

(B.M.-  Brian  Martin,  B.McA-Bruce  McArthur,  G.H. -Gavin  Hemphill,  J.M.-  Joe  Maksym,  I.F-lan  Fraser,  W.R.  Bill 
Roger,  S.McF-Sharon  McFadden,  R.K-  Ron  Kessel,  SIMS  -  Sonar  Information  Management  System, 
COMDAT-Command  Decision  Aid  Technology) 

Clearly,  the  scope  of  the  present  project  requires  that  some  narrowing  of  automation  possibilities  be 
undertaken,  since  the  complete  modelling  of  all  sonar  functions  and  associated  automation 
concepts  would  be  a  formidable  and  labour  intensive  task.  Therefore,  in  consultation  with  the  SA, 
a  decision  was  made  to  concentrate  on  the  core  and  critical  functions  of  sonar  signal  detection  and 
contact  identification. 
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4.3  Identification  of  critical  and  core  tasks 


The  key  central  component  of  any  generic  sonar  system  is  the  requirement  that  all  sonar  data  that 
are  sensed  and  displayed  by  the  system  are  accounted  for.  This  means  that  all  lines  on  a  typical 
sonar  display  must  be  detected  by  the  operator,  interrogated,  analysed,  identified  and  logged.  The 
conduct  of  such  tasks  is  a  pre-requisite  for  subsequent  functions  that  are  important  to  building  the 
underwater  picture,  and  which  typically  include  contact  classification,  contact  range,  speed  and 
track  estimation  and  threat  assessment.  Thus  it  follows  that  none  of  these  tactically  critical 
functions  can  be  successfully  executed  if  the  prior  tasks  are  performed  inadequately. 

Thus,  the  baseline  system  to  be  modelled  should  include  the  tasks  of  detecting  sonar  data  of  interest 
from  noise  and  the  process  of  analysis  that  results  in  a  classification  into  the  formal  categories  of: 
unknown,  suspect,  friend,  neutral  and  hostile. 

While  this  process  represents  a  core  component  in  any  sonar  processing  system,  it  should  be  noted 
that  it  represents  just  a  small  sub-set  of  the  entire  range  of  sonar  analysis  that  would  normally  be 
conducted  in  an  operational  context,  as  exemplified  in  the  following  diagram,  which  has  been 
provided  courtesy  of  Navy  Sea  Training.  Note  that  the  functions  selected  for  modelling  fall  within 
the  area  indicated  by  the  grey  box  and  within  this  the  focus  will  be  largely  on  narrow  band  (NB) 
analysis. 
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Figure  2:  Detailed  task  flow  of  the  search-to-analyse  process  that  reflects  current 

Canadian  Navy  Concept  of  Operations. 
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4.4  Operational  environment 

The  environment  comprises  a  deep-water  operation  in  the  context  of  a  typical  Canadian  Navy  Task 
Group  (TG)  comprising  one  mission  essential  unit,  a  destroyer,  three  frigates  and  an  MPA.  The 
TG  is  moving  at  a  speed  of  12  knots.  This  is  considered  to  be  a  broadly  representative 
configuration. 

The  start  of  the  modelled  process  assumes  that  a  watch  handover  has  taken  place  and  the  operators 
have  received  intelligence  and  briefings  concerning  potential  contacts  and  threats.  The  sensor 
system  has  been  deployed  and  has  been  transmitting  data  over  previous  watches. 

4.5  System  Hardware 

In  order  to  approximate  the  realities  of  existing  sonar  systems  the  hardware  constraints  have  been 
set  as  follows: 

•  Two  high-resolution  monitors 

•  Processed,  narrow  band,  sonar  data  are  represented  on  44  beams  (although  in  principle 
this  number  may  be  readily  manipulated).  A  beam  is  considered  to  be  a  cone  of 
reception  that  projects  on  a  specific  bearing  from  the  sensor  system.1 

•  Data  are  represented  as  frequency  information  over  time.  There  are  three  display 
resolutions  per  monitor  which  approximate  single,  triple  beam  and  search  summary 
formats  of  CANTASS. 

•  Broadband  information  is  not  displayed 

•  Aural  presentation  of  sonar  data  is  available  to  operators 

•  The  baseline  system  does  not  employ  auto-trackers,  or  operator  initiated  tracks. 


4.6  Number  of  operators 

This  is  a  system  parameter  that  could  be  systematically  manipulated  if  desired.  As  a  starting  point 
we  have  assumed  a  manning  level  of  two  operators,  who  each  perform  all  of  the  tasks  in  parallel. 
This  would  seem  to  be  a  sensible  starting  point  for  the  model  based  upon  existing  operational 
circumstances  and  what  is  known  about  the  associated  typical  operator  workload.  Unlike  existing 
systems,  we  have  chosen  not  to  add  an  additional  “operator”  to  assist  in  the  task  of  classification. 
Although,  the  baseline  model  could  be  readily  modified  to  accommodate  any  number  of  personnel 
who  perform  any  of  the  core  operations. 


1  While  the  concept  in  the  generic  model  is  that  of  a  beam,  in  fact  this  could  represent  any  type  of  sensor 
configuration  (e.g.  multiple  sonabuoys)  which  will  require  a  multiple  representations  that  will  exceed  the 
capacity  of  a  single  screen,  and  therefore  require  a  multi-screen  format.  Thus,  when  the  term  beam  is  used 
throughout  the  report,  it  should  be  interpreted  to  represent  any  single  sonar  display  that  represents  a  depiction 
of  one  subset  of  the  total  sonar  data. 
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4.7  The  underwater  model  and  sonar  contacts 


The  detailed  simulation  of  the  complexity  of  the  underwater  environment  and  its  interactions  with  the 
wide  range  of  sonar  data  that  are  created  by  mechanical  and  non-mechanical  sources  is  beyond  the 
scope  of  a  baseline  model.  Instead,  we  start  with  the  assumption  that  there  are  a  number  of  sonar 
sources  that  will  have  a  variety  of  sound  frequency  components  that  arrive  at  the  sensor  and  are 
presented  on  a  display,  or  can  be  heard  through  headphones  or  speakers.  These  sonar  data  may  come 
from  biological  or  mechanical  sources  whose  frequency  characteristics  may  be  known  or  unknown 
and  are  associated  with  a  certain  probability  of  being  detected  from  random,  background  noise.  Note 
that  there  is  no  attempt  to  represent  or  simulate  this  noise  in  itself.  Thus  the  sonar  database  comprises 
a  number  of  signal  representations  that  correspond  to  sources  that,  when  processed  by  the  operators, 
should  result  in  identifications  of  non-mechanical,  unknown,  suspect,  or  known.  The  particular 
frequency  characteristics  and  the  numbers  and  types  of  signal  sources  are  described  later  in  this  report 
in  the  section  that  provides  a  full  description  of  the  model. 

4.7.1  Target  spatial  dynamics 

Since  the  baseline  model  does  not  include  tasks  of  localisation  or  target  motion  analysis,  nor  can 
include  the  complexities  of  TG  movement  through  the  ocean,  sonar  sources  are  represented  on  a 
single  beam  only.  Further,  we  do  not  represent  whether  the  sonar  data  arrive  from  bottom  bounce, 
direct  path  or  convergence  zone.  While  this  may  be  unrealistic  of  many  operational  conditions  it 
does  faithfully  represent  the  task  of  detecting  and  identifying  sonar  contacts  that  are  represented  on 
a  single  beam. 

The  model  function  assigns  lines  of  data  randomly  to  the  44  beams. 

4.7.2  Target  temporal  dynamics 

A  further  constraint  on  the  contact  sources  targets  is  that  their  associated  data  are  defined  as  having 
a  finite,  temporal  lifespan  that  will  enter  into  the  simulated  underwater  environment  at  varying 
points  in  time.  In  this  way,  the  information  available  to  the  operator  will  change  over  time  and,  if 
the  data  are  not  processed  before  they  expire,  then  contacts  will  be  missed  or  misclassified. 

We  have  used  the  following  logic  to  determine  the  time  each  line  will  be  available  to  be  processed 
by  the  operators: 

A  variable  named  "life"  is  assigned  a  random  value  between  200  and  600  seconds  using  the 
function: 

life  =  randlnt(200,  600); 

if  clock<300  then  (life  +=  ( 300  -  clock); 

expiration  [tag]  =  clock  +  life; 

A  unique  array  variable  named  "expiration[tag]"  is  assigned  to  each  line.  The  value  of  this  variable 
indicates  the  exact  clock  time  when  the  line  will  scroll  off  the  screen.  The  value  of  expiration[tag] 
is  calculated  by  adding  the  current  clock  time  (system  clock)  plus  the  random  value  of  the  variable 
named  "life". 

An  exception  occurs  during  the  first  300  seconds  of  the  simulation  when  the  array  is  being 
populated  with  lines.  During  this  time  the  Operators  are  not  permitted  to  carry  out  any  tasks.  A 
special  calculation  is  required  to  prevent  lines  from  being  missed  before  the  Operators  are 
permitted  to  start  searching.  If  the  current  clock  time  is  less  than  300  seconds,  the  value  of  "life"  is 
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calculated  by  adding  the  value  of  "life"  plus  the  difference  between  300  seconds  and  the  current 
clock  time  (i.e.  300  -  clock). 

4.7.3  Target  range  prediction 

Under  normal  operational  circumstances  the  operator  will  calculate  the  range  at  which  lines  of 
specific  frequencies  can  be  expected  to  be  detected.  This  will  depend  upon  the  contacts  that  can  be 
expected  and  that  are  provided  in  the  Threat  Assessment  Pack  as  well  as  the  underwater  conditions 
that  will  influence  propagation.  For  the  purposes  of  this  initial  baseline  model,  we  have  assumed 
that  this  process  has  been  done  and  that  all  lines  that  enter  into  the  model  represent  lines  that 
exceed  the  range  prediction  criteria.  If  necessary,  this  is  a  process  that  could  be  modelled  in  the 
future. 

4.7.4  Sonar  data  types 

We  have  modelled  four  characteristics  of  sonar  data  as  follows: 

•  Source  is  a  true  target 

•  Source  is  noise 

•  Sonar  data  may  require  the  operator  to  wait  for  additional  screen  updates 

•  Sonar  data  scroll  off  the  display  before  the  operator  has  time  to  make  an  identification. 
The  probability  with  which  each  of  these  was  generated  within  the  IPME  model  and  the  function 
logic  is  shown  in  the  following  table. 
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Signal  Event  Type 

Probability 

Case 

Description 

Real  Sonar  Signal 

p=  0.22 

Line  Confirmed 

Sonar  signal  has  scrolled  up  screen  far 
enough  to  indicate  a  line  of  interest. 

Confirmed  Line 
Continues 

A  line  of  interest  has  begun  to  scroll  up 
the  screen. 

Signal  with  insufficient 
data 

p=  0.33 

Unconfirmed  Line 
Begins 

A  line  has  started  at  the  bottom  of  the 
screen  but  has  not  been  on  screen 
enough  cycles  to  confirm  it  is  a  line  of 
interest. 

Unconfirmed 

Transient  Begins 

A  transient  has  started  at  the  bottom  of 
the  screen  but  has  not  been  on  screen 
enough  cycles  to  confirm  it  is  a  transient. 

Unconfirmed  Noise 
Begins 

A  noise  line  has  started  at  the  bottom  of 
the  screen  but  has  not  been  on  screen 
enough  cycles  to  confirm  it  is  just  noise. 

Noise 

p=  0.22 

Noise  Confirmed 

A  noise  line  has  scrolled  up  the  screen 
far  enough  for  the  operator  to  confirm  it 
is  just  noise. 

Transient  Confirmed 

A  transient  has  scrolled  up  the  screen  far 
enough  for  the  operator  to  confirm  it  is  a 
transient. 

Line  scrolls  off  screen 

p=  0.22 

Confirmed  Line 

Scrolls  Off  Screen 

A  line  of  interest  has  started  to  scroll  off 
the  top  of  the  screen.  The  Operator  is 
unable  to  distinguish  the  line  from  noise. 

Noise/Transient 

Scrolls  Off  Screen 

A  noise  line  has  started  to  scroll  off  the 
top  of  the  screen.  The  Operator  is 
unable  to  determine  if  this  is  signal  or 
noise. 

Table  3:  Characteristics  of  sonar  data 
4.7.5  Target  identification  characteristics 

This  task  could  be  modelled  in  a  variety  of  methods  depending  on  the  level  of  complexity  of  the 
human  processes  that  are  to  be  simulated.  To  simplify  the  task  we  have  assumed  that  there  are  20 
lines  on  each  beam  (associated  with  a  target)  that  have  to  be  present  before  the  target  can  be 
identified.  If  such  lines  are  not  present,  then  the  target  is  either  missed  or  classified  as  unknown. 
Because  the  task  of  generating  20  frequencies  at  each  beam  requires  a  large  amount  of  IPME  code 
and  CPU  processing  time,  we  have  simulated  this  process  by  only  using  half  as  many  lines  per 
target  per  beam,  but  requiring  that  there  are  two  lines  at  each  frequency  that  have  to  be  present  for 
the  target  to  be  identified.  This  arrangement  generates  identification  times  that  are  consistent  with 
the  wide  range  of  actual  ID  latencies  that  occur  under  operational  conditions. 

Again,  it  should  be  noted  that  this  function  could  be  simply  modified  in  future  versions  of  the 
model  to  generate  different  temporal  characteristics  to  the  identification  process. 
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4.7.6  Ownship/TG  data 

These  data  result  from  the  sensor  array  picking  up  on  a  continuous  basis  acoustic  data  generated  by 
noise  sources  on  the  ship  towing  the  array  and  other  members  of  the  TG.  These  data  are  ever 
present  and  can  at  times  “overwhelm”  the  display,  in  the  words  of  a  sonar  SME.  As  a  result  of 
information  received  during  the  validation  process  (see  section  8),  and  after  discussions  with  the 
Scientific  Authority,  it  was  decided  not  to  populate  the  system  with  TG  data,  but  instead  model  the 
operator  processes  in  dealing  with  “virtual  data”  directly.  For  the  purposes  of  expediency  and 
practicality  two  values  were  chosen  for  the  numbers  of  lines  per  ship,  representing  a  low  and 
moderately  high  TG  “noise”.  For  the  low  condition,  the  operator  would  be  required  to  “process” 

25  lines  per  ship,  each  represented  on  five  different  beams  for  each  of  the  five  ship  TG  for  a  total  of 
625  lines  for  the  entire  TG.  For  the  high  condition  there  were  100  lines  per  ship,  for  a  total  of  2500 
TG  wide.  It  should  be  noted  that  such  values  could  be  simply  changed  in  the  model  depending 
upon  future  user  needs. 

4.8  The  operator  model 

There  are  two  functionally  separate  elements  of  the  operator  model  -  the  basic  search  and  analysis 
for  contacts  of  interest  and  the  sanitisation  of  the  array  of  the  known  lines  arising  from  the  TG. 

One  operator  is  assigned  the  task  of  search  and  analysis  only,  while  the  second  operator  is  required 
to  sanitise  the  array  on  a  regular  basis,  and  only  when  finished,  take  on  the  task  of  search  and 
analysis  to  supplement  the  role  of  operator  one. 

The  standard  model  of  operation  assumes  that  each  operator  searches  through  the  beams  in  triple 
beam  mode  to  detect  sonar  data  of  interest,  identify  the  source  and  log  the  relevant  data  for  each 
line  detected.  One  operator  sequentially  searches  up  the  beams  from  1  -44  and  the  other  from  44- 1 . 
When  sonar  data  are  encountered  by  an  operator,  the  search  process  is  halted  and  the 
identification/classification  process  is  started  by  that  operator  on  a  single  beam.  The  operator 
resumes  the  search  at  the  interrupted  point,  once  the  classification  task  is  completed.  Thus,  the 
tasks  of  search  and  classification  cannot  be  performed  in  parallel  by  a  single  operator  and  require 
time-sharing. 

When  one  operator  interrupts  the  search  to  analyse  data,  the  other  operator  continues  to  search 
until,  or  if,  the  conditions  arise  that  require  this  operator  also  to  engage  in  the  analysis  process  that 
results  in  classification. 

At  the  start  of  the  watch  (i.e.  when  the  simulation  commences)  one  operator  will  "sanitise  the 
array"  while  the  other  operator  searches.  Once  this  process  is  complete,  the  operator  will  also 
search  for  contacts.  The  sanitisation  process  will  recur  during  the  watch,  as  part  of  the  ongoing 
search,  as  ownship  and  TG  lines  migrate  across  different  beams  due  to  the  changes  in  relative 
positions  of  the  sensors  and  the  various  ships. 
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5.  Core  functions  and  the  model  of 
information  flow 


The  selection  of  core  functions  for  modelling  is  based  upon  previous  function  and  task  analyses 
and  discussions  with  a  Navy  sonar  SME.  The  functions  were  chosen  because  they  are  time 
consuming,  repetitive,  rely  on  human  judgment  and  memory,  are  possibly  prone  to  error,  and  if 
improperly  or  inadequately  performed  can  lead  to  identification  errors.  These  functions  form  the 
critical,  central  core  of  the  larger  task  of  building  the  underwater  tactical  picture.  If  they  are  not 
performed  with  accuracy  and  in  a  timely  manner,  the  ensuing  tactical  picture  will  be  at  best 
incomplete  or  could  be  outdated  or  even  wrong.  This  in  turn  would  impact  upon  the  assessments 
of  threats  and  have  implications  for  threat  response  and  weapons  deployment.  As  an  example  of 
the  criticality  of  this  process,  HSI  has  witnessed  underwater  identification  errors  in  a  practised 
Navy  team  undergoing  training,  whereby  an  improperly  analysed  underwater  contact  led  to  an 
inappropriate  toipedo  launch  that  compromised  the  ownship  location  to  the  simulated  enemy. 

The  core  functions  that  we  have  identified  are:  sanitizing  the  array,  detection  and  analysis  of  lines 
and  data  logging.  Within  the  constraints  of  the  present  contract  and  under  the  direction  provided 
by  the  Scientific  Authority,  this  report  focuses  on  the  first  two  of  these  only.  The  principle 
elements  that  comprise  these  core  functions  are  shown  in  the  following  flow  diagrams. 

The  first  diagram  describes  the  information  flow,  functions  and  decisions  relating  to  the  task  of 
sanitising  the  array.  The  second  describes  the  search  and  identification  process.  Square  boxes 
represent  tasks:  input  usually  enters  from  the  top,  but  sometimes  may  be  displayed  as  entering  from 
the  side  for  clarity.  Output  always  exits  from  the  bottom.  Diamond  shaped  boxes  represent 
decision  points.  Information  always  enters  from  the  top.  A  flow  of  information  from  "No"  decision 
exits  from  either  side,  and  a  "Yes"  decision  always  from  the  bottom  apex. 

5.1  Sanitising  the  array 

We  have  adopted  the  term  used  by  the  Navy  to  describe  the  process  by  which  ownship  and  TG  lines 
are  accounted  for  in  the  display(s)  of  sonar  data.  This  process  can  be  considered  to  be  a  necessary 
function  that  has  to  be  performed  for  any  type  of  sonar  system  that  will  be  sensitive  to  the  reception 
of  ownship  and  TG  propagations  and  hence  populates  the  resulting  displays  with  data.  Under  normal 
operational  conditions  there  can  be  as  many  as  1000  lines  emanating  from  the  TG,  that  is,  about  200 
per  ship  and  each  line  could  be  represented  on  several  beams.  These  lines  correspond  to  multiple 
discrete  noise  sources  on  each  ship,  each  of  which  generates  a  fundamental  frequency  and  several 
related  harmonics.  In  such  cases,  a  single  operator  could  spend  almost  an  entire  watch  on  the 
sanitisation  process  alone.  The  presence  of  such  data  on  the  sonar  displays  has  three  major 
implications  for  operator  performance.  First,  they  will  increase  search  time  for  other  sonar  lines  of 
interest  on  any  single  display.  Second,  they  make  the  task  of  identification  and  classification  of  other 
contacts  held  on  the  same  display  more  difficult.  (Indeed,  an  enemy  tactic  may  be  to  take  up  a 
position  in  which  ownship  data  may  be  masked  or  obscured  by  ownship  or  TG  data.)  Third,  they  add 
considerable,  overall  workload  because  the  process  is  more  or  less  continuous  (see  below). 

Sanitising  the  array  is  essentially  a  top-down  process  by  which  the  operator  uses  information  that  is 
available  from  the  log,  Threat  Assessment  Pack  or  watch  handover  messages  to  direct  the  search 
for  lines  associated  with  ownship  and  TG.  As  the  operator  finds  the  required  lines  on  the 


HurnansysfemY  Incorporated 


Prototype  IPME  model  of  sonar  analysis 


Page  19 


appropriate  beams,  the  operator  enters  the  required  information  into  the  log.  All  lines  associated 
with  ownship  and  TG  must  be  accounted  for  and  entered  into  the  log. 

Since  the  relationship  between  the  array  and  ownship  and  TG  will  change  during  the  course  of  a 
watch,  the  beams  on  which  the  associated  data  are  received  will  also  change;  also  changes  in  a 
contact’s  speed  and  the  electro-mechanical  systems  in  operation  will  change  the  frequencies  sensed 
and  displayed.  Thus,  the  requirement  for  sanitisation  will  recur  throughout  the  watch.  However,  in 
contrast  to  the  initial  process  by  which  all  ownship  and  TG  data  are  accounted  for  on  all  beams,  the 
subsequent  tasks  of  sanitisation  that  occur  during  the  standard  search,  take  place  on  a  beam  by 
beam  basis  (as  each  beam  is  scrutinised  sequentially  as  part  of  the  standard  search).  Therefore, 
these  subsequent  acts  of  sanitisation  become  embedded  within  the  overall  search  and  detect 
functions  performed  by  the  operators.  For  present  purposes,  we  have  required  the  operator  to  re¬ 
sanitise  the  array  after  a  delay  of  1 0  minutes  following  the  previous  sanitisation. 

The  information  flow  diagram  for  this  is  shown  on  the  following  page.  The  specific  tasks  and 
decisions  represented  in  this  diagram  will  now  be  described  and  the  initial  assumptions  concerning 
their  performance  dynamics  are  outlined. 

Review  Threat  Assessment  Pack  (TAP)-  ownship  lines :  The  TAP  is  a  source  of  accumulated 
information  concerning  known  sonar  data  of  interest.  It  could  be  expected  to  contain  frequency 
characteristics  and  areas  of  probability  of  known  contacts  as  well  information  about  ownship  and 
TG  sonar  data.  The  operator  reviews  the  TAP  to  find  information  concerning  which  beams  to  look 
on  and  which  frequencies  to  look  for  concerning  ownship  lines. 

Sub-tasks: 

Locate  TAP 
Scan  TAP 

Select  beam:  based  upon  the  information  obtained  from  the  TAP,  the  operator  will  select  the  triple 
beam  set  that  is  likely  to  contain  the  lines  of  interest. 

Sub-tasks: 

Menu-select  to  bring  up  beam  on  display 

Search  beam  for  ownship/TG:  The  operator  scans  the  triple  beam  set  for  evidence  of  sonar  data  at 
the  frequency  of  interest.  Performance  here  will  depend  upon  the  number  of  lines  present  on  the 
beam  and  the  detectability  of  the  individual  lines. 

Are  all  ownship  data  accounted  for  on  this  beam?  This  decision  is  the  outcome  of  the  search.  If  the 
answer  is  “no”,  the  operator  iterates  through  the  search  process.  If  there  is  evidence,  then  the 
operator  continues  with  the  next  task. 

Sub-tasks: 

Scan  each  beam 
Detect  signal 

Remember  lines  associated  with  TG  member  of  interest 
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Are  all  ownship 
Data  accounted  for 
on  this  beam? 

T 


◄ 


Are  all  TG  Data 
accounted  for  on 


Figure  3:  Information  flow  diagram  to  illustrate  the  sanitisation  process 
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Are  ownship  lines  in  log?  Prior  to  entering  the  lines  in  the  log,  the  operator  checks  to  see  if  they  are 
already  there.  If  they  are  the  operator  proceeds  to  the  next  step,  if  not  the  operator  enters  the  lines. 

Sub-task: 

Scan  through  pages  of  log 
Detect  appropriate  log  entry 

Log  ownship  lines  on  this  beam :  The  operator  logs  a  number  of  pieces  of  information  concerning 
the  sensor  configuration,  environmental  and  oceanographic  conditions  as  well  as  the  beam  number 
and  frequencies  associated  with  ownship.  The  first  set  of  information  concerning  context  may 
take  up  to  30  seconds  to  log,  onto  which  must  be  added  the  time  for  each  line  frequency  entry. 

Are  all  beams  accounted  for?  If  the  TAP  and  experience  indicate  that  ownship  lines  are  likely  to  be 
held  on  adjacent  beams,  the  operator  must  check  this  out  by  calling  up  the  display  for  those  beams, 
if  not  already  part  of  the  current  triple  beam  set.  If  all  beams  are  accounted  for,  the  operator 
proceeds  to  the  sanitisation  process  for  the  TG  lines.  If  not,  the  operator  reverts  back  to  selecting 
another  beam  for  inspection. 

Sub-task 

Menu  select  other  beams 

The  process  for  sanitising  the  array  for  TG  lines  is  essentially  the  same  as  that  for  ownship  lines, 
except  that  it  must  be  repeated  for  each  of  the  four  remaining  members  of  the  TG. 

At  the  completion  of  this  process  all  lines  associated  with  the  TG  will  have  been  accounted  for  and 
logged  and  the  operator  now  proceeds  to  the  last  beam  (#43)  to  commence  the  search  for  other  sonar 
data  by  scanning  the  beams  in  the  reveres  order  from  the  other  Operator. 

5.2  The  search  and  identification  process 

The  tasks  and  decisions  are  described  below  and  are  illustrated  in  the  diagram  on  the  next  page.. 

Select  triple  beam  set :  The  operator  selects  the  initial  triple  beam  set  to  be  examined.  As  mentioned 
earlier,  search  is  conducted  serially  through  the  beams,  with  one  operator  starting  at  beam  1  and  the 
other  at  beam  44. 

Search  triple  beam  set',  the  operator  searches  through  each  of  the  beams  in  the  set  for  acoustic  data 
in  the  form  of  pixels  that  are  brighter  than  the  background  noise.  The  operator  will  need  to  wait  for 
at  least  three  screen  updates  for  sufficient  visual  evidence  to  accumulate. 

Sub-tasks: 

Menu-select  to  bring  up  beam  on  display 

Is  there  evidence  of  a  signal?  The  operator  decides  whether  the  accumulated  information  provides 
evidence  of  a  sonar  signal  source.  If  there  is  no  evidence,  the  operator  goes  back  and  selects  the 
next  triple  beam  set. 

Sub  tasks 

Scan  each  beam 
Detect  signal 

Is  it  real  or  statistical  noise?  Based  upon  experience,  the  operator  decides  whether  the  signal  is 
being  produced  by  "random"  statistical  noise,  or  is  evidence  of  a  real  sonar  contact.  If  it  is  deemed 
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to  be  noise,  the  operator  continues  the  search  for  a  signal.  If  it  is  real,  the  operator  goes  to  the  next 
step  of  examining  the  data  more  closely. 


▼  ▼ 


Select  Triple 
Beam  Set 

%  I  T 

Search  Triple 
Beam  Set 


Check 

Database 


Is  the  datum 
from  a  known 
target? 


Is  there  other 
evidence 


Is  there 
evidence  of 
Signal? 


Is  it  real  or 
statistical 
noise? 


Examine  Single 
Beam 


Is  the  source 
mechanical? 


Check  Log 


Is  the  datum 
Logged? 


Is  the  datum 
likely  from  TG? 


Are  there 
other  related 
data?  / 


Search  for 
other  data 


Are  other  data 
found? 


Are  there  any 
other  data  on 
beam? 


Figure  4:  Information  flow  diagram  to  illustrate  the  basic  search 

and  identify  process 
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Examine  single  beam:  The  operator  changes  from  triple  beam  to  single  beam  mode  in  order  to 
examine  the  data  more  precisely. 

Sub  tasks: 

Menu  select: 

Detect  signal: 

Is  the  source  mechanical?  Based  upon  experience,  the  operator  decides  if  the  source  of  the  noise  is 
mechanical  or  non-mechanical  (e.g.  biological).  If  the  latter,  then  the  operator  resumes  the  search. 
If  the  noise  is  thought  to  be  mechanical  in  origin  the  operator  proceeds  to  the  next  task. 

Check  the  log :  the  operator  checks  the  log  to  see  if  this  line  has  already  been  entered,  i.e.  accounted 
for. 

Sub  task: 

Scan  through  pages  of  log 

Is  the  datum  logged?  If  the  datum  associated  with  this  line  is  already  logged,  the  operator  checks 
the  log  information  and  if  the  entry  appears  to  be  valid  for  the  current  line,  returns  to  the  search 
process.  If  there  is  no  entry,  or  if  it  appears  that  the  line  could  be  part  of  a  different  sonar 
signature,  the  operator  continues  with  the  next  step. 

Check  database :  The  database  refers  to  any  source  of  information  that  may  contain  data  of 
relevance  on  the  current  line.  It  could  be  part  of  the  TAP,  notes  left  by  the  previous  shift,  a 
communication,  another  operator  etc.  In  any  event,  some  time  will  be  spent  while  the  operator 
determines  whether  there  is  any  useful  information  available  for  this  line. 

Sub  tasks  (potential  tasks  only  -  not  all  may  be  done) 

Check  TAP 
Check  paper  messages 
Check  handover  log 

Is  the  line(datum)  from  a  known  target?  Based  upon  the  information  that  is  found,  the  operator 
determines  whether  the  source  is  likely  to  be  known  or  not.  If  it  is  not  a  known  source  the  operator 
must  determine  if  there  is  any  other  evidence  that  could  assist  in  providing  more  information  on 
this  line.  If  it  is  a  known  source,  the  operator  will  then  look  for  other  lines  that  are  known  to  be 
associated  with  this  source  (information  flow  skips  the  following  three  steps) 

Is  there  other  evidence?  The  operator  checks  all  potential  sources  that  could  provide  information 
on  the  line.  If  there  is  not,  then  the  operator  proceeds  to  identify  the  source  as  unknown.  If  there  is 
other  evidence,  the  operator  proceeds  to  identify  the  probable  source. 

Sub  tasks: 

Listen  to  acoustic  data 

Check  information  from:  other  sonar  systems,  other  platforms,  helo,  MPA,  GCCS 

ID  unknown :  in  the  absence  of  any  information  on  the  line,  the  operator  identifies  it  as  "Unknown" 

Enter  Log:  The  operator  enters  all  relevant  information  on  the  line  into  the  log  and  assigns  the 
formal  ID  of  unknown.  The  operator  then  resumes  the  search. 

Are  there  other  related  lines?  If  information  held  on  the  line  suggests  that  it  is  associated  with  a 
source  which  does  not  generate  any  other  lines,  and  the  line  is  unique  to  this  source,  then  the 
operator  can  formally  identify  the  source  (friend,  hostile,  neutral).  If  the  information  held  on  this 
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line  suggests  that  it  is  associated  with  a  source  that  generates  other  lines,  then  the  operator  needs  to 
search  for  those  lines  to  complete  (or  not)  the  identification  process,  (skip  next  two  steps). 

Tag  data:  the  operator  annotates  the  display  to  indicate  that  the  current  data  are  associated  with  a 
particular  ID, 

ID  source',  if  the  information  held  uniquely  identifies  the  source,  the  operator  IDs  the  source  and 
enters  the  information  into  the  log  and  then  resumes  the  search. 

Search  for  other  lines  (data)'.  If  other  lines  should  be  expected  to  be  present  that  are  associated  with 
the  first  line,  then  the  operator  searches  for  these  specific  lines  proactively. 

Sub  tasks: 

Select  other  beams 
Scan  other  beams 

Are  all  other  lines(data)  found?  If  the  other  expected  lines  are  found,  the  operator  can  then  ID  the 
source  and  Enter  the  log.  If  the  other  expected  lines  are  not  found,  the  operator  will  ID  the  source 
as  possible,  then  Enter  log  and  then  resume  the  search. 

Are  there  other  lines  on  beam ?  The  operator  returns  to  triple  beam  and  checks  to  see  if  there  are 
any  further  unaccounted  lines  on  the  current  beams.  If  there  are  no  lines  then  the  search  is  resumed 
with  a  new  triple  beam  set.  If  there  are  other  lines,  then  the  appropriate  single  beam  is  selected  and 
the  process  repeated  from  that  point. 
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6.  The  IPME  model 


In  this  section  we  outline  the  functionality  of  the  IPME  sonar  model  for  the  core  tasks  of  searching 
for,  and  identifying,  contacts  of  interest  and  building  the  underwater  picture,  and  provide  a  high- 
level,  but  detailed  description  of  how  each  function  operates.  A  more  detailed  listing  of  the 
specific  functions  and  logic  is  provided  in  Annex  A  and  B. 

The  development  of  the  IPME  has  followed  the  following  steps,  which  are  recommended  in  the 
IPME  User’s  Guide. 

6.1  Statement  of  the  problem 

The  goal  of  the  model  is  to  look  at  the  impact  of  some  form  of  automated  decision  aid  on  the 
performance  of  a  sonar  system.  In  this  particular  case  we  have  examined  the  impact  of  a  semi- 
automated  function  to  assist  in  the  process  of  sanitising  the  array.  The  assessment  of  the 
performance  of  the  modelled  system  under  baseline  and  semi-automated  conditions  is  achieved 
through  a  number  of  measures  that  are  either  performance  based  or  operator  based.  The  three 
major  performance  measures  are  the  number  of  log  entries  for  lines,  the  total  number  of  lines 
missed  and  the  number  of  times  the  array  is  sanitised  per  session.  The  operator  measures  are  in 
terms  of  overall  workload,  and  the  sub-scale  workload  associated  with  visual,  auditory,  cognitive 
and  psychomotor  processes. 

Thus,  two  IPME  models  will  be  constructed,  one  to  generate  baseline  data  for  non-assisted 
decision  making  and  the  second,  which  incorporates  the  decision  aid. 

6.2  Analysis  of  the  process 

As  indicated  in  section  5  above,  the  core  processes  have  been  identified  and  analysed  in  order  to 
understand  the  process  thoroughly  and  to  determine  the  key  tasks,  the  sequence  in  which  they  are 
performed,  what  resources  they  use,  whether  there  are  any  restrictions  on  when  they  can  be 
performed  (for  example,  only  when  certain  resources  are  available  or  after  certain  events  have 
occurred),  and  how  they  affect  the  overall  system  being  modeled.  Validation  of  these  core 
processes  was  obtained  through  a  detailed  review  of  the  tasks  by  a  highly  experienced  Navy  Sonar 
Sea  Trainer. 

The  next  step  in  the  analysis  was  to  determine  how  the  times  for  each  task  are  distributed — that  is, 
what  probability  distribution  characterizes  the  task,  and  what  values  are  appropriate  for  the 
distribution  parameters  (usually  mean  and  standard  deviation).  An  initial  estimate  of  these 
parameters  was  made  by  HSI  staff  with  some  familiarity  with  sonar  operations.  Subsequently, 
these  estimates  were  refined  in  consultation  with  the  Navy  SME. 

6.3  The  network  diagram 

The  functions  and  tasks  were  then  converted  into  a  network  diagram  using  IPME  tools.  The  tasks 
could  represent  mental  processes,  physical  processes,  and  processes  that  are  not  actually  performed 
by  anyone  or  anything.  For  example,  we  used  a  task  to  generate  the  sonar  data  that  populates  the 
model  and  another  task  to  represent  the  process  of  making  a  decision  that  can  result  in  several 
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possible  alternative  paths  to  following  tasks.  The  Queue  tool  was  also  used  to  place  queues  in  front 
of  any  tasks  for  which  entities  may  need  to  wait. 

The  complete  network  diagram  for  the  model  is  illustrated  in  Annex  A. 

6.4  Definitions:  how  tasks,  decisions  and  queues  operate 

The  information  derived  from  the  function  and  task  analysis  was  used  to  define  timing  information, 
execution  constraints,  and  the  effects  of  the  task  on  the  system  at  large.  Information  about  sub¬ 
networks  (constraints  on  their  execution)  was  also  defined  as  well  as  routing  decisions  (decision 
type  and  routing  conditions),  and  queues  (their  order,  priority,  and  effects  on  the  system).  For  each 
task  function  information  could  be  provided  for  each  of  the  following  categories: 

•  Function  name  and  number 

•  Description 

•  Triggering  Conditions 

•  End  conditions/consequences 

•  Properties:  distribution  shape,  mean  time,  standard  deviation,  probability  of  failure 

•  Consequences  of  failure:  task  affected,  percent  time  or  failure  degradation 

•  Workload  rating  (see  Table  1:  visual,  auditory,  cognitive,  psychomotor) 

The  information  entered  was  based  upon  HSI  knowledge  base  and  expert  input  provided  by  the 
sonar  SME. 

Details  of  these  functions  definitions  are  provided  in  Annex  B. 

6.5  Definitions:  scenario  events. 

Scenario  events  provided  a  way  to  assign  values  to  variables  independent  of  when  an  entity  begins 
or  ends  a  task  or  enters  or  departs  a  queue.  The  expression  assigning  the  value  could  be  scheduled 
to  occur  at  a  specific  clock  time  or  when  a  specific  condition  is  met  in  the  task  network  model. 
Events  could  be  defined  to  represent  different  scenarios  for  the  process  that  was  modeled  thereby 
allowing  one  task  network  model  to  represent  differences  within  your  process  instead  of  having  to 
develop  completely  different  network  models. 

6.6  Definitions:  the  variables  and  system  changes. 

Once  the  elements  in  the  network  diagram  were  defined  parameters  and  starting  values  for  global 
and  local  variables  were  established.  In  addition  to  these  variables,  other  system  characteristics  that 
should  be  represented  with  variables  were  identified  as  well  as  all  important  counts  and 
measurements  that  change  as  the  simulation  progresses.  All  changes  in  the  value  of  each  variable 
as  task  or  queue  effects  were  also  identified. 

6.7  Definitions:  custom  functions 

Specific  definable  functions  that  are  called  in  tasks,  queues,  or  scenario  events  were  developed  as 
required. 

Definitions  for  each  of  the  above  Model  categories  are  provided  in  Annex  B. 
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6.8  Definitions:  the  environment  model 


IPME  allows  a  detailed  description  of  the  task  environment  to  be  included  into  the  overall  IPME 
model  and  which  will  impact  upon  the  model  performance  according  to  predefined  algorithms. 

The  values  were  selected  by  members  of  the  ETSI  team  familiar  with  Navy  operations  and  then 
validated  by  a  Navy  SME.  The  values  were  intended  to  representative  a  normative  state,  rather 
than  a  worst-case  scenario.  They  may  be  easily  manipulated  in  the  future  if  one  wished  to  look  at 
the  effects  of  degraded  operational  conditions  upon  system  performance.  Definitions  for  the 
environmental  model  are  provided  in  Annex  C. 

6.9  Definitions:  the  crew  model 

The  crew  model  was  defined  using  a  similar  process  to  that  of  the  environmental  model,  again 
assuming  normative  conditions.  Details  of  the  crew  model  are  to  be  found  in  Annex  E. 

6.10  Workspace  and  micro  models 

IPME  allows  a  simulation  of  the  exact  workspace  to  be  constructed  based  upon  measurements  of 
the  work  space  and  the  locations  of  smaller  areas  and  objects  with  respect  to  the  larger  ones.  It  also 
allows  sub-tasks  such  as  keyboard  entry,  mouse  manipulation,  eye  and  head  movements  to  be 
modeled  at  a  micro  level. 

Given  that  the  intention  of  the  current  project  was  to  build  a  generic  representation  of  a  sonar  system,  it 
was  deemed  inappropriate  to  consider  extending  the  analysis  down  to  the  level  of  defining  a  specific 
workspace  and  identifying  the  precise  motor  tasks  that  would  be  required  to  support  task  execution. 
Particularly,  since  the  operator  machine  interface  could  be  optimized  in  a  variety  of  modes  that  could 
include  touch  screen,  smart  menus,  voice  interaction,  display  filtering  etc. 

6.11  Error  checking 

As  the  model  was  developed,  the  built-in  error  checking  system  was  used  to  help  locate  errors  in 
the  model.  Errors  could  be  in  lower-level  logic  such  as  tasks  and  sub-networks  that  are  not 
connected,  queues  with  no  release  condition,  or  undefined  variables.  Expressions  were  also 
checked  for  syntax  errors.  The  model  was  also  independently  reviewed  by  another  SME  to  check 
for  errors. 
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6.12  Running  and  debugging  the  model. 

As  the  model  runs,  variables  were  displayed  to  monitor  their  values,  in  addition  the  event  queue 
was  also  displayed  to  allow  us  to  monitor  events  as  they  are  waiting  to  be  executed.  The  trace  file 
was  also  enabled  to  record  the  time  when  each  task  began  and  ended.  These  options  helped  us 
verify  that  the  model  was  operating  as  intended,  and  identified  where  changes  needed  to  be  made. 
Once  the  model  was  running  smoothly,  snapshots  were  defined  to  collect  values  of  variables  at 
specified  points  during  model  execution.  These  provided  further  validation  that  the  model  was 
operating  correctly  and  identified  possible  problem  areas. 
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Automation 


By  automation,  we  mean  the  assignment  of  functions,  which  are  now  performed  in  an  operator¬ 
intensive  manner,  to  the  system  hardware  and  software,  either  fully  or  partially.  As  we  have 
outlined  in  section  4.2,  there  exist  many  possibilities  for  automation  that  would  lead  to  overall 
improvements  of  human-system  performance.  In  consultation  with  the  Scientific  Authority,  it  was 
decided  to  select  the  task  of  sanitising  the  array  (and  its  generic  equivalent)  as  a  first  candidate  for 
automation.  There  are  several  reasons  for  this.  First,  it  is  a  highly  critical  task,  which  if  not  done 
correctly  can  result  in  degraded  detection  and  identification  of  contacts.  Second,  it  is  a  labour 
intensive  process  that  may  be  subject  to  operator  error.  Third,  it  is  a  time  consuming  and  repetitive 
process  that  consumes  valuable  operator  resources.  Fourth,  it  does  not  require  of  the  operator 
much  in  the  way  of  a  cognitive  effort  (a  "brain  dead"  task).  Thus,  a  system  in  which  the  operator 
workload  and  potential  for  error  is  significantly  reduced  would  free  up  the  operator  to  perform 
more  complex  tasks,  which  in  turn  could  result  in  higher  levels  of  motivation  and  vigilance. 

Before  considering  how  such  automation  would  affect  the  functions  to  be  performed  and  the  flow 
of  information,  it  would  seem  appropriate  to  consider  another  strong  candidate  for  automation, 
namely  the  entry  of,  and  data  retrieval  from  the  log.  This  task  shares  many  of  the  undesirable 
characteristics  of  the  task  of  sanitisation  in  that  it  is  repetitive  and  has  low  cognitive  demand,  yet  is 
a  critical  function  to  the  correct  operation  of  the  system.  Post-mission  analysis  of  the  accuracy  of 
the  log  (against  ground  truth  from  sonar  data  recorded  during  the  mission)  suggests  that  error  rates 
may  be  as  high  as  20%2.  Such  error  rates  in  data  entry  will  then  subsequently  affect  analysis  and 
identification  resulting  in  potentially  missed  identifications,  false  alarms  and  incorrect 
identifications.  Therefore,  we  will  include  the  tasks  of  log  data  entry  and  look-up  as  part  of  the 
automation  model. 

Although  we  refer  to  the  technology  solution  in  this  section  as  automation,  what  we  are  really 
describing  is  a  process  of  machine-assisted  decision  making,  rather  than  full  automation.  This 
seems  a  more  realistic  intermediate  technology  that  could  be  implemented  in  the  short  term  with 
few  other  complications  ensuing,  such  as  issues  of  operator  trust  in  the  automated  process.  A  fully 
automated  system  of  sanitising  the  array  would  eliminate  completely  the  need  for  an  operator  to 
track  lines  associated  with  ownship  and  TG  and  might  even  suppress  these  lines  from  being 
displayed.  Thus,  the  operator’s  only  task  might  be  to  check  the  initial  parameters  settings  of  the 
automated  process  and  then  to  verify  at  a  regular  interval  that  the  process  was  running  correctly 
and  to  fine  tune  the  parameters  as  required.  Instead  of  this  fully  automated  process,  we  have 
considered  a  smart  decision  aid  to  assist  the  operator  and  reduce  both  workload  and  the  time 
required  to  perform  the  function. 

7.1  Description  of  the  model 

The  model  will  be  described  in  detail  in  terms  of  the  human  components  and  how  these 
components  interact  with  the  automation.  There  is  no  attempt  to  document  how  the  automation 
will  be  enabled  at  a  technical  level.  First,  we  will  present  a  description  of  the  two  processes  to  be 
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automated  and  then  a  revised  information  flow/decision-action  diagram  to  show  the  entire  search- 
identify  process. 

7.1.1  Semi-automated  "sanitisation" 

Create  ownship/TG  database :  in  order  for  the  automation  process  to  recognise  ownship  lines,  a 
database  will  need  to  be  constructed.  The  creation  of  this  database  could  itself  be  a  highly 
sophisticated,  semi-automated  function.  In  which  case,  operators  might  just  enter  the 
environmental  and  oceanographic  conditions,  names  of  ships  in  the  TG,  depth  of  the  array  and 
range  sensing  thresholds  and  spatial  arrangement  of  the  TG,  planned  vector  of  the  TG  and  planned 
vectors  of  individual  ships.  The  system  would  then  compute  which  likely  frequencies  would  be 
held  on  which  beams  and  how  these  would  change  over  time.  Given  that  this  degree  of 
sophistication  may  require  a  degree  of  "machine  intelligence"  with  associated  programming 
capabilities  that  may  be  difficult  and  or  costly  to  achieve,  a  simpler  version  of  the  database  would 
appear  to  be  a  more  attractive  first  option  to  contemplate. 

The  simpler  database  would  comprise  a  history  of  the  frequencies  and  beams  associated  with  the 
TG  that  are  manually  entered  and  accumulated  over  time.  Thus,  given  that  the  Canadian  Navy 
might  tend  to  patrol  in  standard  TG  configurations,  the  spatial  relationship  between  the  received 
sonar  frequencies  and  beams  and  TG  configuration  could  result  in  the  creation  of  a  series  of 
templates.  Thus,  for  TG  configuration  A,  there  would  be  a  range  of  expected  frequencies  and 
bearings  associated  with  each  member  of  the  TG. 

Such  a  database  would  generate  two  new  "operator  functions"  -create  database  for  current  mission 
and  update  database  for  local  circumstances. 

Update  ownship/TG  database:  operator  selects  from  a  set  of  pull-down  pre-configured  lists  of 
options  appropriate  settings  for  the  current  context.  The  list  would  include  items  such  as:  relevant 
oceanographic/environment  conditions,  TG  configuration,  TG  speed  and  direction,  expected 
detection  ranges.  These  operations  would  require  a  minimum  of  keystrokes  and  alphanumerical 
data  entry. 

As  an  alternative,  the  process  of  updating  the  database  could  itself  be  highly  automated  whereby 
current  TG  data  on  position,  speed,  equipment  in  operation  (i.e.  noise  sources)  and  oceanographic 
conditions  could  be  directly  incoiporated  into  the  database  model  from  data  already  held  in  other 
databases  within  the  TG. 

For  the  purposes  of  our  simulation  and  current  model,  we  have  assumed  that  the  task  of  creating 
the  database  has  been  taken  care  of,  and  that  the  operator  signing  off  the  previous  watch  had 
updated  the  database.  Thus,  when  the  operator  starts  the  new  watch,  the  system  is  ready  and 
prepared  for  the  task  of  sanitizing  the  array.  We  assume  that  this  procedure  would  be  initiated  with 
a  simple  menu  selection  and  the  system  then  displays  the  appropriate  triple  beam  set  that  shows  the 
data  for  the  first  TG  member. 

Review  TG  data  for  current  context:  The  operator  reviews  the  signature  pattern  against  the  data  on 
the  projected  bearing  generated  from  the  database  for  accuracy  against  the  current  sonar  data  and 
fine  tunes  the  database,  as  required.  This  could  be  considered  an  abbreviated  version  of  the  initial, 
operator-intensive  task  of  "sanitising  the  array"  and  should  result  in  considerable  time  saving 
compared  with  existing  practice.  Subsequently,  this  task  will  be  repeated  either  as  a  pre-scheduled 
element  of  watch  duty  (say  every  10  minutes),  or  the  task  could  be  triggered  by  changes  in  the  TG 
configuration,  or  environmental  conditions,  or  ownship/TG  speed  or  array  depth  etc. 
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The  results  of  this  semi-automated  process  could  be  presented  in  a  number  of  ways  to  the  operator. 
The  simplest  way  would  be  to  have  the  system  display  lines  automatically  associated  with  ownship 
and  TG  using  colour  coding.  This  would  make  them  readily  distinguishable  from  other  lines  on  a 
beam  and  would  speed  the  search  and  identification  for  other  lines.  A  second  alternative  would  be 
to  display  all  lines  as  they  are  currently  (i.e.  monochrome)  but  allow  the  operator  to  interrogate 
them  by  placing  a  cursor  over  the  line.  This  would  result  in  the  presentation  of  a  small  pop-up 
window  above  the  line  that  displays  the  contact/line  association  held  in  the  database. 

Once  the  data  are  correctly  entered  and  appropriately  configured  for  the  current  context,  they  are 
available  for  access  on  an  ongoing  basis  as  the  operator  interrogates  each  line  on  each  beam. 

Such  a  degree  of  automation  runs  the  risk  of  inducing  operator  complacency  and  acceptance  of  the 
accuracy  or  truth  in  what  is  being  displayed.  Thus,  other  contacts  (in  particular  hostiles),  which 
have  frequency  characteristics  in  common  with  those  being  displayed  as  part  of  ownship/TG,  run 
the  risk  of  being  overlooked  for  closer  scrutiny  and  analysis.  Therefore,  there  will  be  a  need  for  the 
operator  to  conduct  a  proactive,  verification  check  each  time  a  tagged  line  is  encountered  before 
proceeding  to  the  next  line. 

7.1.2  Semi-automated  data  logging  and  retrieval. 

In  present  sonar  operations  data  logging  can  be  a  manually  intensive  process  that  requires  the 
operator  to  key  in  all  of  the  required  data  with  respect  to  environmental,  oceanographic, 
array/sensor  conditions  as  well  as  the  data  associated  with  the  specific  line  of  interest  such  as  beam 
(bearing),  frequency  and  possible  source,  if  known.  Data  entry  for  the  contextual  information 
currently  takes  about  30  seconds  with  an  additional  2-3  seconds  for  each  line  to  be  entered.  This 
process  could  be  semi-automated  as  follows. 

Log  data :  The  current  environmental  and  contextual  conditions  would  be  presented  in  a  pre- 
configured  format  and  would  only  require  data  entry  by  exception.  That  is,  if  any  of  the  conditions 
have  changed  since  the  last  line  logged,  the  operator  would  only  have  to  enter  the  changes  through 
a  simple  menu  selection.  The  remaining  part  of  the  data  entry  could  be  accommoda  ted  by  having 
the  operator  position  the  cursor  over  the  line  of  interest,  thereby  allowing  the  system  to  capture  the 
beam  and  frequency.  The  operator  would  then  enter  the  contact  information  through  a  pre- 
configured  set  of  options  (e.g.  trk#,  poss/prob/unknown,  friendly,  neutral,  hostile  etc).  Estimated 
time:  5-10  seconds. 

Verify  data :  The  operator  reviews  the  data  entered  by  the  above  procedure,  modifies  the  entry,  if 
required  and  then  confirms  the  entry.  Estimated  time  5-10  seconds.  Anticipated  error  rate:  less  than 
1%. 

Check  log :  similar  to  the  process  of  displaying  data  for  ownship/TG,  the  process  of  holding  a 
cursor  over  a  line  of  interest  could  result  in  a  pop-up  window  above  the  line  that  shows  the  log  data 
for  that  line.  By  selecting  the  track#  for  that  line  the  operator  could  see  all  of  the  lines  associated 
with  the  track  highlighted  on  the  display  and  could  also  review  the  time  history  of  the  track  and 
lines  in  a  separate  window  if  required. 

7.1.3  Semi-automated  sanitisation:  Information  flow  and  decision/action  diagram 

The  core  function  for  the  automated  sanitisation  process  is  “ Review  TG  data  for  current  context ” 
and  the  detailed  decomposition  into  the  tasks  and  information  flow  for  this  are  shown  in  Figure  5. 

A  description  and  explanation  of  each  of  the  tasks  and  decisions  follows.  As  a  starting  point  of  the 
process  we  assume  that  a  database  of  ownship  and  TG  data  has  already  been  completed  at  some 
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prior  point  in  time  and  has  been  recently  updated  by  the  outgoing  watch.  Thus,  the  first  task  of  one 
operator  on  the  new  watch  will  be  to  check  the  information  contained  in  the  database. 

The  operator  initiates  the  sanitise  decision  aid  which  displays  the  first  TG  signature  on  the 
appropriate  beams,  and  the  operator  performs  the  following  series  of  tasks.  These  tasks  are 
repeated  until  all  members  of  the  TG  have  been  accounted  for. 

Display  data  for  ownship/TG.  This  is  accomplished  rapidly  through  the  selection  of  a  dedicated 
function  key  and  the  system  automatically  displays  ownship  or  TG  data  on  an  appropriate  beam. 

Does  pattern  match  lines  displayed?  The  known  signature  pattern  is  shown  overlaid  on  the  beam 
data  and  the  operator  makes  a  visual  pattern  match  with  the  sonar  data  on  that  beam.  If  the  pattern 
matches,  the  operator  proceeds  to  the  next  task.  The  number  of  lines  to  be  matched  depends  on  the 
overall  volume  of  lines  generated  by  the  TG/ownship.  For  the  purposes  of  the  model,  we  have 
assumed  either  25  or  100  lines  are  present  on  each  beam  from  each  TG  ship.  If  the  pattern  matches, 
the  operator  proceeds  to  process  other  beams  on  which  the  data  are  found. 

If  the  pattern  does  not  match  the  data  on  the  display,  the  operator  analyses  the  data  to  determine 
whether  the  lines  in  question  are  likely  coming  from  ownship  (or  TG(n))  and  if  they  do,  then 
updates  the  database  with  the  current  ownship/TG  data  to  indicate  any  change  in  frequencies  and 
proceeds  to  the  next  task.  If  they  do  not  seem  to  be  part  of  the  expected  pattern,  the  operator 
resumes  with  the  next  task. 

We  have  arbitrarily  set  the  probability  that  the  lines  will  match  as  p=.85,  on  the  basis  that  if  the 
database  is  accurate  and  updated  frequently,  there  would  be  a  low  probability  of  the  data  displayed 
being  incorrect  for  the  current  circumstances.  This  number  could  be  easily  manipulated  in  the 
future  to  reflect  lower  probabilities  associated  with  more  dynamic  movement  among  the  TG 
members  relative  to  the  sensing  array  or  changes  in  oceanographic  conditions  that  may  not  have 
been  incorporated  into  the  current  database  model. 
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"Does  pattern  match 


Are  all 

ownship/TG(n) 
accounted  for? 


Search 


Figure  5:  Information  flow  diagram  of  the  semi-automated  sanitise  process. 


Humansystems*  Incorporated 


Prototype  IPME  model  of  sonar  analysis 


Page  34 


Are  all  beams  accounted  for?  Based  upon  the  information  in  the  database  concerning  the  expected 
pattern,  the  operator  will  normally  need  to  check  other  beams  on  which  the  ownship/TG  data  may 
be  displayed.  For  the  purposes  of  the  model  we  have  assumed  that  the  lines  are  present  on  five 
different  beams.  If  all  beams  are  not  accounted  for  the  operator  iterates  through  the  steps  in  the 
process  of  reviewing  the  pattern  for  all  remaining  beams.  Once  all  of  the  beams  for  that  TG  ship 
have  been  processed  the  operator  goes  to  the  next  task. 

Are  all  ownship/TG  signatures  accounted  for?  The  operator  checks  to  see  if  all  signatures  in  the 
TG  have  been  accounted  for  and  iterates  through  the  whole  process  until  they  are.  This  would  be  a 
fairly  straightforward  task  that  is  prompted  semi-automatically  by  the  system.  That  is,  the  software 
controls  the  presentation  for  each  successive  member  of  the  TG.  Once  all  ships  are  all  accounted 
for,  the  operator  resumes  the  standard  search  through  the  display  for  sonar  lines  of  interest. 
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Validation 


The  validation  of  the  model  was  a  two-step  process  involving  intensive  discussions  with  a  senior 
Navy  Sea  Trainer  responsible  for  sonar  systems.  In  the  first  step  and  early  in  the  project 
development,  the  overall  sonar  detection  and  analysis  process  was  reviewed  in  depth  and  the  roles 
and  tasks  of  the  operators  fully  decomposed  and  discussed.  This  initial  process  resulted  in  the 
generation  of  the  basic  search-detection  model  and  provided  ideas  on  critical  tasks  that  would  be 
suitable  for  assessing  the  effects  of  automation. 

The  second  stage  of  validation  required  that  the  resulting  IPME  sonar  model  be  thoroughly 
reviewed  for  accuracy  and  completeness.  Three  aspects  of  the  model  were  reviewed  with  the  sonar 
SME:  (1)  the  system  functions  and  information  flow,  (2)  the  times  associated  with  the  functions 
and  expected  error  rates  and  (3)  the  visual,  auditory,  cognitive  and  psychomotor  (VACP)  workload 
ratings  associated  with  each  function.  In  particular,  the  semi-automated  approach  to  sanitisation 
was  reviewed  in  detail,  since  this  was  an  “invention”  of  the  HSI  team  and  needed  to  be  scrutinised 
by  an  SME. 

Essentially,  the  basic  system  functions  and  their  information  flow  were  largely  validated.  A  small 
number  of  functions  were  re-labelled  and  some  were  dropped  or  shifted  among  the  operators. 

There  were  a  significant  number  of  changes  made  to  the  task  timings  and  error  rates,  largely  as  a 
result  of  under-estimating  the  values  in  the  initial  model  concept.  There  were  minor  and  few 
changes  to  the  VACP  values. 

The  most  significant  outcome  of  the  validation  process  was  new  information  provided  on  the 
magnitude  and  scope  of  the  sanitisation  process.  The  number  of  ownship/TG  lines  to  be  analysed 
was  severely  underestimated  in  the  model  and  we  were  given  feedback  that  the  number  of  lines 
varies  enormously  depending  upon  operational  circumstances.  The  range  could  be  anywhere 
between  25  to  200  lines  per  ship,  which  translates  into  125  to  1000  for  the  TG.  Further,  these  lines 
could  be  present  on  from  5  to  40  beams  depending  upon  the  specific  oceanographic  conditions  and 
the  distance  and  relative  bearing  of  the  TG  from  the  sensor  array. 

The  way  an  operator  processes  these  data  is  to  first  pull  up  a  bearing  and  then  to  use  a  harmonic  or 
other  smart  cursor  to  identify  the  fundamental  and  related  harmonics  of  each  noise  source  on  the 
ship.  Once  all  sources  have  been  identified  on  the  beam  in  question  they  are  logged  and  the 
operator  moves  onto  other  beams.  Subsequently,  the  process  of  identifying  the  sources  on  the  other 
beams  goes  somewhat  faster  in  that  the  operator  having  identified  the  pattern  already,  can  largely 
proceed  with  individual  pattern  matching  on  subsequent  beams,  supplemented  by  analysis  where 
the  pattern  does  not  quite  match. 

As  a  result  of  this  feedback  on  the  volume  of  lines  associated  with  the  TG  and  the  process  used  to 
analyse  them,  the  IPME  model  was  revised  in  agreement  with  the  Scientific  Authority.  The 
revisions  comprised  two  parts.  First,  instead  of  the  model  generating  the  large  number  of  TG  lines 
for  operator  processing  and  distributing  these  lines  to  different  beams  (and  updating  as  the  TG 
spatial  relationships  changed  over  time),  the  model  was  revised  to  reflect  only  the  human  operator 
component.  That  is,  the  times  for  the  operators  to  perform  the  various  tasks  were  modelled,  with 
no  underlying  sonar  data  being  “processed”.  The  second  aspect  of  the  revision  concerned  what 
volume  of  line  processing  should  be  modelled.  This  decision  is  somewhat  arbitrary  as  the  model 
can  be  easily  revised  to  incoiporate  other  levels  of  loading.  For  practical  purposes  and  to  allow  the 
simulation  to  run  in  a  reasonable  amount  of  time,  we  selected  two  levels  of  “line  load”  a  low  end 
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estimate  of  25  lines  per  ship,  each  being  represented  on  five  beams,  that  is  a  total  of  625  lines  for 
the  entire  TG  and  sensor  array,  and  a  moderate  to  high  level  of  100  lines  per  ship.  Our  estimate  was 
that  the  latter  would  take  the  operator  over  7  hours  to  complete  the  task  of  sanitisation.  Again  it 
should  be  stressed,  that  the  number  of  lines  and  beams  carrying  the  lines  are  model  parameters  that 
may  be  easily  changed  in  the  future  depending  on  the  specific  objectives  in  employing  the  model. 

The  feedback  from  the  SME  on  the  proposed  semi-auto  sanitisation  process  was  very  positive  and 
the  functionality  was  very  much  in  line  with  what  he  envisaged  would  be  an  optimum  approach. 
One  function  was  removed  from  the  initial  process,  which  we  had  developed.  This  involved  the 
operator  checking  for  the  possibility  of  other  non  -TG  signatures  that  could  be  present  on  a  beam 
which  showed  a  similar  pattern  to  a  TG  ship.  The  SME  suggested  that  such  a  task  would  be 
assigned  to  the  other  operator  as  part  of  his  responsibility  for  detecting  and  analysing  non-TG  data. 
As  a  result,  this  function  was  removed  from  the  model. 
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Performance  of  the  model 


To  evaluate  the  model,  ten  independent  runs  were  conducted  for  each  of  the  two  levels  of  TG  line 
complexity  (25  or  100)  and  for  the  baseline  and  automated  conditions.  For  each  run,  30000  data 
updates  were  generated  at  a  rate  of  1  per  second,  thereby  simulating  8.3  hours  of  real  time 
operating  conditions.3  The  complete  dataset  of  performance  data  is  being  supplied  in  electronic 
format  as  an  Excel  spreadsheet  file. 

9.1  System  performance  measures 

System  measures  comprised  the  following: 

•  Total  number  of  contacts  ID  and  logged-  decomposed  into 

Total  Source  ID 
Total  Possible  ID 
Total  Unknown  ID 

•  Total  number  of  lines  missed 

•  Total  number  of  wait  lines  (line  is  too  short  for  operator  to  make  decision) 

•  Total  number  of  ignored  lines  (line  is  a  noise  transient) 

•  Total  number  of  lines  too  far  up  the  display  to  allow  a  decision 

•  Number  of  times  the  sanitisation  process  is  completed 

9.2  Operator  measures 

Operator  measures  comprised  a  continuous  sampling  of  the  following  workload  ratings: 

•  Visual 

•  Auditory 

•  Cognitive 

•  Psychomotor 

•  Computed  Within  task  interference 

•  Computed  Between  task  interference 

•  Overall  workload  index 

Of  the  above  measures,  the  following  were  excluded: 

Computed  Between  task  interference :  operators  were  only  allowed  to  do  one  task  at  a  time  -  hence 
there  could  be  no  between  task  interference. 

Overall  workload  index :  without  any  effects  of  between  task  interference,  the  overall  index  is 
equivalent  to  the  within  task  workload  score. 


3  We  should  like  to  acknowledge  the  assistance  of  Braid  Cain  of  DRDC-Toronto  in  conducting  these  data 
collection  runs 
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9.3  Analysis  and  evaluation  of  model  data 

9.3.1  System  performance  measures 

Because  of  the  large  amount  of  data  generated  and  the  redundant  nature  of  some  of  the  measures, 
we  have  selected  three  primary  system  measures  as  being  the  most  representative  and  illustrative  of 
any  performance  differences  between  baseline  and  automated  conditions.  These  measures  are  total 
number  of  contacts  logged,  the  total  lines  missed  and  number  of  times  the  array  is  sanitised  per 
“watch” 

The  raw  data,  means  and  standard  deviations  for  each  of  the  ten  runs  are  shown  in  the  following 
tables,  which  compare  manual  (baseline)  and  automated  conditions  for  both  the  25  line  and  100 
line  TG  conditions. 

Number  of  contacts  logged 


TG=25  lines 

TG=100  lines 

Auto 

Manual 

Auto  Manual 

1 

53 

36 

41 

33 

2 

50 

35 

40 

35 

3 

49 

36 

40 

34 

4 

50 

42 

42 

35 

5 

53 

39 

39 

34 

6 

49 

39 

42 

32 

7 

50 

37 

40 

35 

8 

51 

37 

42 

34 

9 

48 

36 

40 

32 

10 

56 

36 

43 

34 

Mean 

50.9 

37.3 

40.9 

33.8 

SD 

2.42 

2.11 

1.29 

1.135 

Table  4:  Number  of  contacts  logged:  results  of  ten  runs 

These  data  and  associated  error  bars  (+/-  two  standard  error  based  upon  pooled  variance)  are 
illustrated  in  the  following  graph. 
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Figure  6:  Mean  number  of  contacts  logged  per  condition:  variance 
shown  by  +/-  two  standard  error 

Statistical  analysis  of  these  data  show  that  for  both  the  25  line  (t=13.38,  df=18,  p<.01)4  and  100  line 
(t=14.47,  df=18,  p<.01)  conditions  there  was  a  significant  increase  in  the  number  of  contacts  logged 
when  the  task  of  TG  sanitisation  was  semi-automated.  This  difference  corresponds  to  gains  of 
approximately  36%  and  24%  respectively  for  the  25  and  100  line  conditions. 


4  A  one-tailed  test  statistic  was  chosen  since  the  difference  between  the  two  conditions  was  predicted  in  a 
specific  direction. 
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Number  of  lines  missed 


Run  TG=25  lines  TG=100  lines 

Auto  Manual  Auto  Manual 


1 

2571 

2710 

2676 

2674 

2 

2596 

2640 

2694 

2796 

3 

2591 

2662 

2674 

2742 

4 

2674 

2735 

2641 

2731 

5 

2537 

2696 

2650 

2748 

6 

2637 

2723 

2739 

2741 

7 

2619 

2698 

2616 

2751 

8 

2576 

2675 

2655 

2768 

9 

2580 

2727 

2663 

2702 

10 

2510 

2718 

2657 

2754 

Mean 

2589.1 

2698.4 

2666.5 

2740.7 

SD 

47.14151 

30.85882 

33.11 

33.63 

Table  5:  Number  of  lines  missed:  results  of  ten  runs 

These  data  and  associated  error  bars  (+/-  two  standard  error  based  upon  pooled  variance)  are 
illustrated  in  the  following  graph. 


Number  of  Lines  Missed 


25  100 

Number  of  lines  per  TG  ship 


□  AUTO 
D MAN UAL 


Figure  7:  Mean  number  of  lines  missed  per  condition:  variance 
shown  by  +/-  two  standard  error 

Statistical  analysis  of  these  data  show  that  for  both  the  25  line  (t=6.13,  df=18,  p<.01)  and  100  line 
(t=4.97,  df=18,  p<.01)  conditions  there  was  a  significant  decrease  in  the  number  of  lines  missed 
when  the  task  of  TG  sanitisation  was  semi-automated.  This  difference  corresponds  to  gains  of 
approximately  5.3%  and  1.5%  respectively  for  the  25  and  100  line  conditions. 
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The  number  of  times  the  TG  data  were  sanitised 


TG=25  lines 

TG=100  lines 

Auto  Manual 

Auto  Manual 

1 

16 

4 

8 

1 

2 

17 

4 

8 

1 

3 

17 

4 

7 

1 

4 

17 

4 

10 

1 

5 

18 

4 

8 

1 

6 

18 

4 

8 

1 

7 

17 

4 

8 

1 

8 

17 

4 

8 

1 

9 

18 

4 

7 

1 

10 

17 

4 

8 

1 

Mean 

17.2 

4 

8 

1 

SD 

0.63 

0 

0.81 

0 

Table  6:  Number  times  the  TG  data  were  sanitised:  results  of  ten  runs 

Clearly,  in  light  of  the  data,  no  statistical  analysis  is  necessary  to  demonstrate  the  clear  advantage 
of  the  semi-automated  sanitisation  process  over  the  traditional  manual  approach. 

9.3.2  Operator  measures 

Mean  workload  scores  for  each  operator  on  each  of  the  workload  dimensions  for  each  of  the 
experimental  conditions  were  computed  based  upon  the  individual  35225  values  computed  by  the 
IPME  model  during  each  of  the  10  runs.  The  means  of  the  ten  were  then  calculated  and  the 
ensuing  data  are  shown  in  the  following  graphs.  Note  that  Operator  1  performs  just  the  basic 
search  and  identification  task  and  that  Operator  2  does  the  sanitization  process  (manual  or  semi- 
automated)  and  when  finished,  contributes  to  the  basic  search  task.  The  data  are  presented 
separately  for  the  two  sanitisation  conditions  in  which  the  number  of  lines  per  TG  member  was 
either  25  or  100  per  beam. 

Statistical  analysis  of  the  data  was  conducted  using  two-factor  (level  of  automation  and  number  of 
lines  per  TG  ship)  analysis  of  variance  (ANOVA).  Where  necessary,  supplemental  comparisons 
were  made  using  t-tests.  It  was  decided  that  it  would  not  be  appropriate  to  combine  all  of  the 
individual  workload  measures  into  a  single  multivariate  analysis  of  variance,  in  view  of  the  fact 
that  the  auditory  workload  scores  showed  opposite  effects  to  the  other  measures  and  that  the 
separate  workload  indices  are  theoretically  uncorrelated.  Similarly,  no  separate  analysis  was 
conducted  of  the  total  within-task  interference  workload,  since  this  is  not  statistically  independent 
of  the  other  measures. 
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Operator  1 


Operator  1:  25  Lines/TG 
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Figure  8:  Operator  1:  Mean  workload  ratings-25  lines/TG 
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Operator  1:  100  Lines/TG 


□  MAN 
■  AUTO 


.xO 


Figure  9:  Operator  1:  Mean  workload  ratings-100  lines/TG 

The  data  show  that  the  workload  ratings  are  virtually  same  for  both  conditions  of  automation. 

None  of  the  ANOVA  showed  any  significant  (p<.05)  main  effects  or  interactions.  This  is  to  be 
expected  as  this  operator’s  tasks  do  not  change,  even  when  Operator  2  has  more  time  available  to 
work  in  parallel  on  the  basic  search,  as  should  occur  in  the  automated  condition.  In  other  words, 
Operator  1  still  continues  to  work  away  and  his/her  task  load  is  unaffected  by  any  available 
capacity  contributed  by  Operator  2.  We  should  only  expect  to  see  any  effect  on  Operator  1  under 
conditions  when  there  are  much  fewer  lines  and  Operator  1  runs  out  of  lines  to  analyse  and  just 
performs  the  routine  search,  thereby  reducing  his  time  averaged  workload  for  the  entire  session. 

Operator  2 

Similar  data  for  this  operator  are  shown  in  the  next  two  figures. 

For  the  both  TG  conditions,  there  seems  to  be  a  small  trend  for  higher  workload  ratings  in  the 
manual  condition  for  visual,  cognitive  and  psychomotor  components,  and  a  reverse  trend  for  the 
auditory  workload  component.  The  effect  of  the  number  of  TG  lines  to  be  analysed  was  not 
consistent.  For  all  workload  measures  except  the  cognitive  (where  the  reverse  was  true),  workload 
was  slightly  higher  in  the  25  line  condition.  Flowever,  these  effects  are  quite  small,  typically  of  the 
order  of  less  than  .  1  on  the  10-point  workload  scale,  but  are  statistically  significant  because  of  the 
small  variance  between  simulation  runs.  The  significant  interactions  for  visual  and  cognitive 
workload  scores  reflected  a  larger  effect  of  the  automation  condition  under  the  100  line  condition, 
compared  with  the  25  line  condition.  This  difference  was  in  the  opposite  direction,  however,  for 
the  psychomotor  scores.  The  major  statistical  analyses  supporting  the  above  statements  are  shown 
in  the  following  table. 
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Measure 

Source 

F  (df  for  all=  1,36) 

Significance 

Visual 

Number  of  lines 

47.46 

p<.01 

Automation 

394.61 

pc.Ol 

Interaction 

56.33 

pc.Ol 

Auditory 

Number  of  lines 

1.42 

NS 

Automation 

126.21 

pc.Ol 

Interaction 

0.12 

NS 

Cognitive 

Number  of  lines 

216.09 

p<.01 

Automation 

831.92 

p<.01 

Interaction 

359.587 

p<.01 

Psychomotor 

Number  of  lines 

136.31 

p<.01 

Automation 

2049.38 

pc.Ol 

Interaction 

242.81 

pc.Ol 

Table  7:  Summary  of  ANOVA  results  for  workload  ratings  for  Operator  2 
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Figure  10:  Operator  2:  Mean  workload  ratings-24  lines/TG 
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Operator  2:  100  lines/TG 


Figure  11:  Operator  2:  Mean  workload  ratings-100  lines/TG 

To  return  to  the  effect  of  automation,  we  were  surprised  initially  to  have  found  the  large  effect  in 
the  auditory  workload  component  in  a  counterintuitive  direction,  which  also  has  a  strong  influence 
in  making  the  composite  within-task  workload  measure  go  in  the  same  direction.  In  order  to 
explore  this  further,  we  looked  at  the  second-by-second  underlying  auditory  data  (from  which  the 
means  are  calculated)  and  found  that  for  the  automated  condition,  the  operator  spends  on  average 
approximately  63%  of  the  time  doing  some  form  of  auditory  analysis,  whereas  in  the  manual  case 
this  figure  is  about  12%  of  the  time.  Thus,  the  advantage  of  the  automated  condition  is  that  it 
allows  the  operator  to  process  more  lines  generally  and  as  a  result,  more  frequent  auditory  analysis 
results,  which  in  turn  affects  the  time  averaged  mean. 

Overall,  we  do  not  find  large  effects  on  workload  resulting  from  the  automation  process,  even 
though  the  effects  are  statistically  significant.  This  is  not  surprising  since  the  operators  in  the  auto 
condition  are  simply  doing  more  or  less  the  same  tasks,  but  performing  them  more  frequently  as  a 
result  of  the  more  efficient  process.  We  should  only  expect  a  large  effect  of  workload  between  the 
two  conditions  to  emerge  when  the  operators  are  less  loaded,  i.e.  there  are  fewer  lines  to  process. 
In  such  a  case,  the  operator  in  the  automated  condition  would  process  all  of  the  lines  faster,  and, 
once  all  lines  have  been  accounted  for,  would  have  only  a  basic  surveillance  function  to  perform, 
which  in  itself  would  carry  a  lower  workload. 
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10.  Summary 


This  project  has  demonstrated  that  the  complex  task  of  conducting  sonar  surveillance,  target 
detection  and  identification  can  be  successfully  simulated  with  a  task  network  model.  The  purpose 
of  the  model  is  to  allow  “what-if  ’  questions  concerning  system  redesign  to  be  answered  a  priori 
without  the  need  to  actually  implement  the  proposed  changes.  In  principle,  the  model  that  has  been 
developed  could  be  readily  modified  to  address  the  following  influences  on  system  performance 
and  operator  workload: 

•  The  number  of  operators 

•  The  number  and  size  of  screens 

•  The  value  of  smart  tools  or  decision  aids 

•  Re-assignment  of  tasks  among  the  team 

•  Operator  processing  and  analysis  re-engineering 

In  addition  to  such  system-based  changes,  environmental  influences  may  also  be  manipulated  such 
as  the  rate  and  number  of  targets,  the  rate  of  system  updates  and  the  signal  to  noise  ratio. 

As  a  demonstration,  we  have  shown  that  the  basic  model  can  be  adapted  to  incoiporate  a  semi- 
automated  function  to  assist  operators  in  the  time  consuming,  repetitive  and  mentally  unchallenging 
task  of  sanitising  ownship  and  TG  lines  from  the  detection  array.  This  model  has  been  tested  and  run 
through  several  trials  to  generate  output  data  that  shows  the  impact  of  the  automation  aid.  This 
impact  is  shown  to  have  a  somewhat  larger  effect  on  system  performance  measures  than  on  operator 
workload.  The  size  of  the  impact  on  system  throughput  (21%-36%  more  lines  logged,  8  times  more 
sanitisations  achieved)  is  probably  of  significant  operational  importance  and  suggests  the  potential 
value  in  a  system  re-design  that  incorporates  such  a  decision  aid.  The  effects  on  operator  workload, 
however,  are  largely  dependent  upon  the  environmental  parameters  selected  to  load  the  operators.  In 
the  present  case,  based  upon  SME  advice,  we  chose  to  simulate  low-medium  and  medium-high 
loadings  on  the  system,  in  terms  of  the  lines  that  were  to  be  processed. 

The  validation  process  that  was  undertaken  provides  some  general  assurance  that  the  tasks,  their 
sequences,  the  decisions  and  actions  are  all  consistent  with  existing  sonar  processing  practices. 
However,  it  should  be  remembered  that  the  specific  parameter  values  chosen  for  the  sonar 
data, represent  exemplars  of  operational  values  and  cannot  be  considered  to  reflect  the  true  range  of 
sonar  contact  data  that  is  found  under  a  wide  variety  of  operational  and  environmental  conditions. 

It  should  be  noted  that  the  values  selected  for  the  crew  and  environmental  models  are  provided  as 
context  for  the  core  IPME  model,  but  do  not  in  themselves  influence  the  performance  of  the  model. 
The  development  of  functions  that  compute  the  effects  of  critical  influences  remains  an  ongoing 
process  by  the  IPME  development  teams  and  the  ability  to  incoiporate  sonar-critical, 
environmental  and  crew  factors  into  the  model  in  the  future,  would  greatly  enhance  the  model’s 
generalisability  and  utility. 
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11.  Limitations  and  Constraints 


11.1  Scope 

The  particular  area  of  sonar  analysis  chosen  for  modelling  represents  just  one  small  aspect  of  the 
overall  functions  and  tasks  performed  within  the  typical  sonar  suite  (see  figure  2).  As  such,  it 
cannot  claim  to  comprehensively  represent  this  entire  process.  However,  it  does  faithfully 
represent  the  core  critical  task  of  the  detection  and  identification  of  sonar  narrow-band  data 
associated  with  contacts  of  interest. 

11.2  Sonar  data 

Throughout  the  description  of  the  model  we  have  referred  to  the  sonar  acoustic  data  as  “lines”,  to 
be  consistent  with  the  terminology  and  concepts  of  CANTASS.  However,  there  is  nothing  in 
principle  that  constrains  the  data  to  being  the  equivalent  of  lines.  The  core  sonar  data  could  have  a 
variety  of  different  characteristics  both  spatial  and  temporal,  as  long  as  the  key  functions  to  be 
performed  by  the  operator  were  detection  and  analysis. 

11.2.1  Spatial  and  temporal  characteristics: 

The  parameters  for  these  were  chosen  to  be  illustrative  of  actual  data  found  in  some  operational 
conditions.  The  specific  values  chosen  influence  the  performance  of  the  model.  For  example, 
changing  the  mean  duration  a  line  is  available  to  be  detected  and  its  spatial  distribution  on  the 
sensor  array  will  greatly  influence  the  number  of  lines  that  an  operator  is  able  to  process.  Further, 
changing  the  number  of  lines  that  must  be  “analysed”  by  the  operator  in  order  to  identify  a  target 
will  also  have  a  large  effect  on  system  throughput  measures. 

11.2.2  Target  data  density 

Variation  from  the  particular  values  chosen  will  cause  the  workload  on  operators  and  their 
simulated  performance  to  change  that  observed.  A  lower  target  rate  would  result  in  operators 
spending  more  time  in  search  and  less  time  in  identification,  with  a  consequent  effect  on  associated 
workload  scores. 

11.3  Operator  characteristics 

The  values  chosen  for  tasks  such  as  contact  detection  rates,  the  probability  of  having  sufficient 
evidence  to  identify,  the  probability  of  encountering  noise  and  the  probability  of  having  a  target 
scroll  off  the  screen  all  effect  system  throughput.  They  provide  a  convenient  baseline  for  the 
comparison  of  changes  in  system  performance  as  a  function  of  manipulating  independent  variables 
of  interest.  As  such,  they  should  not  be  taken  to  be  representative  of  actual  operator  performance 
under  similar  operational  conditions,  nor  should  they  be  regarded  as  normative  of  absolute 
benchmarks  of  performance. 

Similarly,  while  the  values  chosen  for  means,  distributions,  standard  deviations  and  error  rates  for 
operator  tasks  were  based  on  broad  operational  considerations,  other  values  may  also  be 
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appropriate  depending  upon  the  concept  of  task  environment  and  would  have  a  significant  effect  on 
operator  performance  and  workload. 

1 1 .4  Task  and  information  flow 

The  sequence  of  tasks  performed  by  the  simulated  operators  closely  resembles  the  concept  of 
operations  employed  for  the  detection  and  identification  of  narrow  band  sonar  data  in  CANTASS. 
However,  it  should  be  noted  that  this  sequence  of  tasks  and  their  distribution  among  the  operators 
is  only  one  of  many  that  might  be  adopted.  The  present  model  only  permits  operators  to  “perform” 
in  a  somewhat  routine,  serial  manner.  It  does  not  allow  for  task  prioritization,  task  interruption, 
trading  tasks  between  operators,  co-operative  tasking  or  task  backtracking. 

11.5  Length  of  watch 

A  watch  length  of  just  over  eight  hours  was  simulated.  This  value  is  a  key  determinant  of  the 
overall  success  in  sanitising  the  array,  which  can  be  a  process  that  takes  hours  rather  than  minutes. 
Thus,  selection  of  watch  lengths  that  are  much  shorter  will  give  misleading  information  on  the 
comparison  of  sanitisation  performance  between  manual  and  automated  conditions. 

11.6  Simulation  of  mental  processes 

There  is  no  attempt  in  the  model  to  further  decompose  some  complex  tasks  into  the  sequential  steps 
and  associated  mental  activities  that  are  required  for  their  successful  execution.  An  example  of  this 
is  the  function  “ Is  there  any  other  evidence?” ,  which  incorporates  a  variety  of  sub-tasks  that 
involve  checking  other  sources  of  information  such  as  intelligence,  listening  to  the  acoustic  signal 
compiling  and  analysing  evidence  for  a  particular  identification  and  using  a  decision  rule  to  make 
the  judgment.  Each  of  these  tasks  in  themselves  may  be  complex,  have  a  variety  of  time 
distributions  for  task  completion,  have  different  error  rates  and  carry  somewhat  different  workload 
ratings.  Hence,  the  generic  representation  of  all  of  these  task  elements  into  a  single  function  may 
carry  some  risk  since  the  factors  that  influence  these  tasks  differentially,  may  not  be  reflected  in  the 
model  performance. 
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12.  Suggestions  for  future  work 


Two  areas  suggest  themselves  as  the  next  logical  step  to  follow  the  current  work  -  (a)  the  extension 
and  refinement  of  the  model  and  (b)  model  validation. 

12.1  Extension  and  refinement  of  the  model 

The  following  points  represent  opportunities  to  enhance  the  model  scope,  generality  and  fidelity. 

•  Simulate  directly  the  tasks  of  detection,  analysis  and  identification  (and  associated  sub¬ 
tasks  and  operator  mental  processes),  as  compared  to  using  general  performance 
shaping  metrics,  as  is  the  case  with  the  present  model. 

•  Simulate  acoustic  data  analysis 

•  Extend  the  model  to  include  classification 

•  Extend  the  model  to  include  tasks  performed  by  the  Sonar  Supervisor  and  ASWC 

•  Examine  effects  of  other  decision  aids  such  as:  identification  assistance  tools, 
classification  aids  and  data  tagging  and  automated  logging 

12.2  Model  validation 

The  basic  model  functions  and  their  associated  timings,  logic,  failure  rates,  consequences  and  associated 
workload  have  received  nominal  validation  through  discussions  with  a  sonar  SME.  This  validation  is 
based  upon  one  experienced  individual’s  judgment  of  the  appropriate  values.  To  improve  the  validity  of 
the  model  several  options  are  feasible.  First,  we  could  collect  real-time  data  (task  timings,  accuracy, 
error  rates  and  workload)  for  the  core  tasks  in  an  operational  context.  However,  this  is  practically  and 
logistically  difficult  to  accomplish.  Second,  we  could  attempt  to  find  other  SMEs,  with  a  similar 
background  and  experience  judgments  to  the  present  SME,  to  provide  additional  data.  However,  such 
individuals  are  difficult  to  locate,  are  very  busy  and  may  be  so  few  in  number  that  validity  cannot  be 
really  enhanced  to  any  acceptable  statistical  degree.  The  third  approach  would  be  select  critical 
components  of  the  model  to  be  validated  in  an  experimental  paradigm  that  uses  some  of  the  basic  task 
components  of  identification  and  analysis  process.  This  approach  would  involve  developing  tasks  that 
are  highly  similar  to  the  model  core  tasks,  but  which  could  be  performed  by  non-Navy  subjects  with 
sufficient  training.  The  objective  would  be  to  collect  both  performance  data  and  workload  ratings,  so 
that  these  two  critical  aspects  of  the  model  could  be  independently  validated. 

The  experimental  paradigm  should  probably  focus  on  the  following  core  characteristics  of  the  model: 

•  Search  across  a  number  of  display  windows 

•  Detection  of  lines  in  noise 

•  Analysis  of  multiple  line  sets  to  arrive  at  an  identification 

•  Use  of  ancillary  data  to  provide  a  complex  task  of  information  assembly  to  arrive  at  an 
identification 

•  Logging  of  data 

•  Search  of  the  log 

•  Comparison  of  the  manual  and  semi-automated  sanitisation  process  using  a  facsimile  task 

•  The  design  of  the  semi-automated  decision  aid  for  sanitisation  and  the  estimates  of  task 
timings  adopted  in  the  model  for  the  processes  involving  the  aid 
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14.  Glossary 


ASWC 

CANTASS 

HCI 

ID 

IPME 

PSF 

SA 

TAP 

TIAPS 

TG 

VACP 


Anti  Submarine  Weapons  Commander 
Canadian  Towed-Array  Sonar  System 
Human-Computer  Interaction 
Identify 

Integrated  Performance  Modelling  Environment 

Performance  Shaping  Function 

Scientific  Authorty 

Threat  Assessment  Pack 

Towed  Integrated  Active  Passive  System 

Task  Group 

Visual,  Auditory,  Cognitive,  Psychomotor  (workload  dimensions) 
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Annex  A.  Description  of  the  logic  and 
functions  of  the  IPME  Sonar  Model 


The  overall  IPME  model  is  shown  on  the  next  page  as  a  task  network  diagram. 
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Decomposition  of  the  function  “Manual  search” 
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Function  descriptions 


Task 

Event  # 

Task  Title 

Task  Description 

1 

Start 

This  task  uses  a  multiple  decision  to  initiate  the  scenario  by  directing  a  sonar  signal 
to  both  OP2  (to  start  the  Sanitization  process)  and  OP1  (to  start  the  Basic  Search 
process).  This  task  also  sets  Sanitize  Mode  ON.  With  Sanitize  Mode  ON, 

Operatorl  is  responsible  for  searching  for  lines  on  every  beam  in  the  display  while 
Operator  attends  to  Sanitizing  the  array.  Operator  is  set  to  beam  zero,  so 
Operatorl  is  able  to  search  every  beam  in  the  array  without  overlaping  with 
Operator. 

2 

Manual  or 
Auto 

Sanitize 

This  task  prevents  the  initial  sonar  signal  from  entering  the  Sanitize  task  until  the 
scenario  time  has  reached  300  seconds.  During  the  first  300  seconds  of  the 
scenario,  lines  populate  the  triple  beam  display  in  the  Basic  Search  process.  The 
Operators  start  searching  the  display  once  300  seconds  has  passed.  The  value  of 
the  TG  (current  Task  Group  member)  variable  is  set  to  0  to  begin  the  Sanitization 
process.  A  tactical  decision  sends  a  one  tag  to  either  the  Manual  Sanitize  process 
or  the  Auto  Sanitize  process  depending  on  the  value  of  the  variable  named 
"manualSanitize".  If  manualSanitize  is  set  ON  (is  equal  to  1)  the  tag  is  directed  to 
the  Manual  Sanitize  process.  If  manualSanitize  is  set  OFF  (is  equal  to  0)  the  tag  is 
directed  to  the  Auto  Sanitize  process. 

Manual  Sanitize 

3 

Select  TG 

This  is  the  first  task  in  the  Manual  Sanitize  process.  The  value  of  TG  (current  Task 
Group  member)  is  incremented  by  1  to  advance  the  Operator  to  sanitize  the  next 

TG.  The  number  of  beams  remaining  for  the  next  TG  member  is  set  to  5.  The 
value  of  the  variable  named  "experimentMode"  sets  the  number  of  lines  per  beam 
to  either  "Low"  or  "Medium".  If  the  value  of  experimentMode  is  equal  to  1  the 
number  of  lines  per  beam  is  set  to  "Low".  If  the  value  of  experimentMode  is  equal 
to  2  the  number  of  lines  per  beam  is  set  to  "Medium".  A  tactical  decision  routes  the 
tag  to  the  appropriate  TG  member  (TGI  to  TG5)  depending  on  the  current  value  of 
the  TG  variable.  As  the  Sanitization  process  progresses  and  the  Select  TG  task  is 
revisited,  the  value  of  TG  is  incremented  by  1  to  instruct  the  Operator  to  identify  the 
next  Task  Group  member. 

4  to  8 

TGI  to  TG5 

These  tasks  route  tags  to  the  "Select  Beam"  task.  This  task  provides  a  visual 
indication  during  animated  playback  to  indicate  what  TG  member  is  currently  in  the 
process  of  being  detected. 

9 

Select  Beam 

The  functions  named  SearchTime()  and  LogTime()  are  called  by  this  task.  These 
functions  assign  values  to  the  variables  named  searchTime  and  logTime, 
respectively.  The  value  of  the  experiment  variable  named  "experimentMode"  sets 
the  number  of  lines  per  beam  to  either  "1"  or  "2".  If  the  value  of  experimentMode  is 
set  to  1  ("Low")  there  are  25  lines  per  beam.  If  the  value  of  experimentMode  is  set 
to  2  ("Medium")  there  are  100  lines  per  beam. 
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Task 

Event  # 

Task  Title 

Task  Description 

10 

Search 

Beam  for  All 
Lines 

Mean  time  for  this  task  is  set  according  to  the  value  of  a  variable  called 
searchTime.  If  number  of  lines  per  beam  is  set  to  25,  the  mean  time  is  300 
seconds  for  the  first  beam  encountered  and  180  seconds  for  each  beam  afterward. 

If  number  of  lines  per  beam  is  set  to  100,  mean  time  is  set  to  1973  seconds  for  the 
first  beam  encountered  and  to  720  seconds  for  each  beam  afterward. 

11 

Found  All 
Lines 

The  task  mean  time  is  set  to  2.  A  fixed  link  from  this  task  directs  the  tag  to  the  "Log 
Lines"  task. 

12 

Log  Lines 

Mean  time  is  set  according  to  the  value  of  a  variable  called  logTime.  If  number  of 
lines  per  beam  is  set  to  25,  mean  time  is  set  to  30.  If  number  of  lines  per  beam  is 
set  to  100,  mean  time  is  set  to  60. 

13 

More  Beams 
to  Search 

The  task  mean  time  is  set  to  2.  The  value  of  the  variable  named  "remainingBeams" 
is  decreased  by  one  to  advance  the  Operator  to  sanitize  the  next  beam  for  the 
current  Task  Group  member.  A  tactical  decision  following  this  task  routes  lines  to 
either  the  "Select  Beam"  task  if  remainingBeams  has  a  value  greater  than  0  (i.e. 
there  are  more  beams  left  to  search  for  the  current  Task  Group  member)  or  routes 
line  to  the  "All  TG  Done"  task  if  remainingBeams  has  value  equal  to  zero  (i.e.  there 
are  no  more  beams  left  to  search  for  the  current  Task  Group  member). 

14 

All  TG  Done 

The  task  mean  time  is  set  to  2.  A  tactical  decision  following  this  task  routes  lines 
either  to  "Completed  Sanitize"  if  the  variable  called  TG  is  equal  to  5  or  to  "Select 

TG"  if  TG  is  less  than  5. 

Automated  Sanitize 

15 

Auto  Select 
TG 

This  is  the  first  task  in  the  Automated  Sanitize  process.  The  number  of  beams 
remaining  for  the  next  TG  member  is  set  to  5.  The  value  of  the  variable  named 
"experimentMode"  sets  the  number  of  lines  per  beam  to  either  "Low"  or  "Medium". 

If  the  value  of  experimentMode  is  equal  to  1  the  number  of  lines  per  beam  is  set  to 
"Low".  If  the  value  of  experimentMode  is  equal  to  2  the  number  of  lines  per  beam  is 
set  to  "Medium".  A  tactical  decision  following  this  task  directs  the  tag  to  the 
appropriate  "TG#"  task  (ie.  TGI  to  TG5)  depending  on  the  value  of  the  TG  variable. 

16  to  20 

TGI  to  TG5 

This  task  routes  the  tag  to  the  "Display  Data"  task.  This  provides  a  visual  indication 
during  animated  playback  to  indicate  what  TG  member  is  currently  in  the  process  of 
being  detected. 

21 

Display  Data 

The  task  mean  time  is  set  to  2.  A  function  named  "AutoTimings"  assigns  values  to 
variables  that  are  used  as  task  mean  times  for  tasks  22  (patternTime),  23 
(analyzeTime),  and  27  (updateTime).  Task  mean  times  are  set  according  to  the 
value  of  the  "experimentMode"  variable  (i.e.  number  of  lines  per  task  group 
member).  If  25  lines  per  beam  are  used,  mean  times  are  set  to  a  baseline  level.  If 
100  lines  per  beam  are  used,  mean  times  are  increased  by  a  factor  of  4  times. 

22 

Does 

Pattern 

Match 

Display 

The  task  mean  time  is  set  according  to  the  value  of  a  variable  named  "patternTime". 
If  there  are  25  lines  per  beam,  mean  time  is  set  to  10.  If  100  lines  per  beam,  mean 
time  is  set  to  40.  The  standard  deviation  is  set  to  2.  This  task  updates  the  value  of 
the  variable  called  "currentBeam"  with  the  value  of  the  array  variable  called 
"remainingBeams".  The  value  of  remainingBeams  is  decreased  by  one  to  advance 
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Task 

Event  # 

Task  Title 

Task  Description 

the  system  to  sanitize  the  next  beam  for  the  current  Task  Group  member.  A 
probabilistic  decision  following  this  task  routes  tags  to  the  "Are  All  Beams 

Accounted  For?"  task  75  percent  of  the  time  [i.e.  Pattern  does  not  match  lines 
displayed]  and  to  "Pattern  Matches  Lines  Displayed"  task  25  percent  of  the  time. 

23 

Analyze 

Data 

The  task  mean  time  is  set  according  to  the  value  of  a  variable  named 
"analyzeTime".  If  there  are  25  lines  per  beam,  mean  time  is  set  to  60.  If  100  lines 
per  beam,  mean  time  is  set  to  240.  The  standard  deviation  is  set  to  12.  Fixed  link 
to  "Are  Displayed  Lines  From  Ownship/TG?" 

24 

Are  All 

Beams 

Accounted 

For? 

This  task  evaluates  whether  or  not  all  five  beams  for  the  current  Task  Group 
member  have  been  examined.  The  task  mean  time  is  set  to  2.  The  value  of 
"currentBeam"  is  updated  by  the  array  variable  "remainingBeams".  A  tactical 
decision  following  this  task  directs  the  tag  to  "Are  All  Ownship/TG  Lines  Accounted 
For?"  if  the  value  of  the  array  variable  called  "remainingBeams"  is  greater  than  0.  If 
"remainingBeams"  is  equal  to  0,  the  tag  is  directed  to  "Does  Pattern  Match  Lines 
Displayed?" 

25 

Are 

Displayed 
Lines  from 
Ownship? 

The  task  mean  time  is  set  to  2.  A  probabilistic  decision  following  this  task  directs 
the  tag  to  "Display  Data  For  Ownship/TG"  task  85  percent  of  the  time  to  indicate  the 
lines  are  attributed  to  Ownship  or  Task  Group.  Alternatively,  15  percent  of  the  time 
the  decision  the  tag  directs  to  "Update  Database  with  Current  Ownship/TG  Data"  to 
indicate  the  lines  are  not  attributed  to  Ownship  or  Task  Group. 

26 

Are  All 

Ownship/TG 

Lines 

Accounted 

For? 

The  task  mean  time  is  set  to  2.  A  tactical  decision  following  this  task  directs  the  tag 
to  "Completed  Sanitize"  task  if  the  value  of  TG  equals  5.  The  tag  is  directed  to 
"Auto  Select"  to  advance  to  the  next  Task  Group  member  if  TG  is  less  than  5. 

27 

Update  Data 
with  Current 
Ownship/TG 
Data 

The  task  mean  time  is  set  according  to  the  value  of  a  variable  named  "updateTime". 
If  there  are  25  lines  per  beam,  mean  time  is  set  to  30.  If  100  lines  per  beam,  mean 
time  is  set  to  120.  A  fixed  path  from  this  task  leads  to  "Are  All  Beams  Accounted 
For?" 

28 

Display  Data 
for 

Ownship/TG 

The  value  of  the  variable  named  "currentBeam"  is  updated  by  the  array  variable 
"remainingBeams"  to  update  the  number  of  remaining  beams  to  search  for  the 
current  Task  Group  member.  A  tactical  decision  following  this  task  directs  the  tag 
to  Are  All  Ownship/TG  Lines  Accounted  For?"  if  the  value  of  the  array  variable 
remainingBeams  is  equal  to  0  (ie.  The  final  beam  for  the  current  Task  Group 
member  has  been  examined).  The  tag  is  directed  to  "Does  Pattern  Match  Lines 
Displayed"  if  remainingBeams  is  greater  than  0  (ie.  More  beams  for  the  current  TG 
member  remain  to  be  examined). 

Sanitize  Complete 

30 

Completed 

Sanitize 

This  task  occurs  when  the  Operator  has  completed  the  Sanitization  process.  The 
timeSanitized  variable  is  set  to  the  current  time.  The  TimeSanitizedFN  function 
increments  and  sets  the  appropriate  variable  (e.g.  FirstTimeSanitized, 
SecondTimeSanitized,  etc.)  to  record  the  current  time.  The  variable  sanitizeReset 
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Task 

Event  # 

Task  Title 

Task  Description 

is  incremented  by  one.  The  value  of  the  variable  "Op2Detect"  is  set  to  1  to  enable 
Operator  to  detect  lines  in  the  Basic  Search  process.  The  value  of  sanitizeMode 
is  set  to  0  to  activate  the  OpBeam  Function  and  to  enable  Operator  to  examine 
Beam  number  43.  The  Sanitization  process  terminates  at  this  task  and  Operator 
joins  the  Basic  Search  process. 

29 

Manual 

Search 

(Group 

Network) 

This  task  is  triggered  at  the  start  of  the  simulatiion.  It  directs  a  tag  to  the  Basic 
Search  process  to  begin  generating  lines  on  the  array. 

Basic  Search 

29.1 

Generate 
Sonar  Signal 

This  task  increments  the  tag  variable  to  continuously  generate  sonar  signals  for  the 
Basic  Search  process  at  a  rate  of  one  new  signal  every  10  seconds.  Reducing  this 
mean  will  increase  the  number  of  lines  per  second  generated  by  the  model.  A 
function  called  TypeFN  assigns  one  of  four  possible  signal  types  to  the  tag  (e.g. 

Real  Signal  of  Interest  [identify],  Noise  [ignore],  Partial  Incomplete  Signal  [wait], 
Expired  Signal  [proceed  to  next]).  The  TypeFN  function  generates  a  random 
number  between  1  and  9  that  is  coded  to  a  signal  type.  Numbers  1  and  2  are 
coded  as  "Real"  sonar  signals  generated  by  a  mechanical  source.  Real  signals  are 
lines  repeated  over  several  cycles  of  the  sonar  display.  Numbers  3,  4,  and  5  are 
incomplete  lines  which  are  not  yet  identifiable  because  they  are  not  long  enough  to 
distinguish  between  signal  or  noise.  These  incomplete  lines  could  be  real, 
transient,  or  noise  signals.  The  operator  must  wait  for  more  sonar  display  cycles 
before  making  this  determination.  Numbers  6  and  7  are 

29.2 

Select  Triple 
Beam  Set 

The  mean  time  is  set  to  1.5  with  a  standard  deviation  of  0.15  seconds.  The  variable 
named  totalLines  is  incremented  by  1  to  count  the  number  of  lines  generated  by  the 
model.  A  tactical  decsion  following  this  task  directs  the  line  to  the  appropriate  beam 
according  to  the  array  variable  named  beam. 

29.3  to 
29.17 

Beam  1-3 
Examine  to 
Beam  43 
Examine 

The  task  mean  time  is  calculated  using  a  formula  based  on  the  number  of  lines  on 
the  beam  (4  +  #linesA1.3).  The  task  mean  time  is  set  to  0  if  the  tag  has  passed  it's 
expiration  time.  The  value  of  beam[beam#]  is  set  to  1  when  a  line  enters  the  task 
and  0  when  the  line  exits  the  task  to  ensure  the  operator  is  only  able  to  examine 
one  line  at  a  time.  The  value  of  Op#Buffer  is  updated  by  the  value  of  bufferjbeam#] 
and  Op#Tags  is  updated  by  the  value  of  beam[beam#]  value.  These  variables  are 
used  to  determine  if  there  are  any  lines  currently  being  examined  on  the  current 
beam.  An  array  variable  named  Op  is  used  to  associate  the  current  line  to  the 
Operator  who  detected  it  so  all  tasks  carried  out  involving  this  line  assign  workload 
to  the  correct  Operator.  A  variable  named  die  is  updated  by  the  array  variable 
expiration  [tag]  to  display  the  expiration  time  for  the  current  line.  A  tactical  decision 
following  this  task  directs  the  line  either  to  "Missed"  if  the  value  of  the  array  variable 
expiration  [tag]  is  le 
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Task 

Event  # 

Task  Title 

Task  Description 

29.18 

Signal  or 
Noise 

The  task  mean  time  is  set  to  10.  This  task  updates  the  value  of  the  variable  called 
"classifyType"  with  the  value  of  the  array  variable  called  "type[tag]"  to  display  the 
type  identity  of  the  line  (e.g.  Signal,  Transient,  Noise,  etc.).  The  value  of  Op#Detect 
is  set  to  0  to  prevent  the  current  Operator  from  detecting  additional  lines  during  the 
identification  process.  A  tactical  decision  following  this  task  directs  the  line 
depending  on  the  value  of  the  variable  named  classifyType.  The  "Select  Single 
Beam"  branch  is  followed  if  the  line  is  type  1  or  2;  the  "Wait"  branch  is  followed  if 
the  line  is  type  3, 4,  or  5;  the  "Ignore  Noise"  branch  is  followed  if  the  line  is  type  6  or 
7;  and  the  "Go  To  Next"  branch  is  followed  if  the  line  is  type  8  or  9.  An  alternative 
branch  leading  back  to  "Start"  is  followed  if  600  seconds  have  passed  since  the 
Sanitization  process  has  been  completed  and  the  current  Operator  is  Operation. 
This  branch  restarts  the  Sanitization  process  and  removes  Operator  from  the 

Basic  Search 

29.19 

Missed 

This  task  is  designed  to  count  the  number  of  missed  lines.  The  value  of  the 
variable  named  "missed"  is  incremented  by  1  each  time  a  line  arrives  at  this  task. 
The  value  of  Op#Detect  is  set  to  1  to  allow  the  Operator  to  examine  the  beam. 

29.21 

Ignore  Noise 

This  task  is  designed  to  count  the  number  of  noise  signals  detected  by  the 

Operator.  The  value  of  the  variable  named  "ignored"  is  incremented  by  1  each  time 
a  line  arrives  at  this  task.  The  value  of  Op#Detect  is  set  to  1  to  allow  the  Operator 
to  examine  the  beam. 

29.22 

Wait 

This  task  is  designed  to  count  the  number  of  incomplete  lines  detected  by  the 
Operator.  The  value  of  the  variable  named  "wait"  is  incremented  by  1  each  time  a 
line  arrives  at  this  task.  The  value  of  Op#Detect  is  set  to  1  to  allow  the  Operator  to 
examine  the  beam. 

29.23 

Go  to  Next 

This  task  is  designed  to  count  the  number  of  lines  which  have  started  to  disappear 
off  the  top  of  the  display  and  moved  to  the  next  beam.  The  value  of  the  variable 
named  "gotonext"  is  incremented  by  1  each  time  a  line  arrives  at  this  task.  The 
value  of  Op#Detect  is  set  to  1  to  allow  the  Operator  to  examine  the  beam. 

Identification  Process 

29.20 

Select 

Single  Beam 

(Group 

Network) 

Directs  the  tag  to  the  Identification  process. 

29.20.1 

Select 

Single  Beam 

The  task  mean  time  is  set  to  2  with  a  standard  deviation  of  0.4  seconds.  This  task 
has  a  fixed  link  to  the  task  "Is  Source  Mechanical?" 

29.20.2 

Is  Source 
Mechanical? 

The  task  mean  time  is  set  to  5.  This  task  has  a  fixed  link  to  the  task  "Check  Log" 

29.20.3 

Check  Log 

The  task  mean  time  is  set  to  20  with  a  standard  deviation  of  5.  This  task  has  a 
fixed  link  to  the  task  "Is  Line  Logged?" 
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Task 

Event  # 

Task  Title 

Task  Description 

29.20.4 

Is  Line 
Logged? 

The  task  mean  time  is  set  to  0.5  with  a  standard  deviation  0.005.  The  task  calls  a 
function  named  "SubDetect"  that  identifies  the  beam  where  the  current  line  was 
detected  and  calls  a  function  named  "Sub[beam#]Contact"  which  identifies  the  line 
frequency  (ranging  between  1  and  10),  records  the  line  in  computer  memory  by 
incrementing  the  value  of  the  variable  named  "det[beam#]_freq[frequency#]"  by  1, 
and  calls  another  function  named  "Sub[beam#]Log".  The  function  called 
"Sub[beam#]Log"  examines  the  number  of  times  each  line  on  the  current  beam  has 
been  logged.  If  all  20  lines  on  this  beam  have  been  logged  (ie.  the  value  of  the  10 
variables  "det[beam#]_freql"  to  "det[beam#]_freql0"  are  greater  than  2),  the  array 
variable  named  "moreRelatedLines"  is  set  to  1.  This  variable  is  used  to  determine 
the  outcome  of  the  tactical  decision  following  the  task  "Are  There  Other  Related 
Lines?"  A  tactical  decision  following  this  task  directs  the  line  to  "Check  Database"  if 
the  line  has  not  already  been  logged  or  to  "Searc 

29.20.5 

Search 

Triple  Beam 
Set 

This  task  terminates  if  the  line  has  already  been  logged.  The  variable  named 
Op#Detect  is  set  to  1  to  enable  the  Operator  to  carry  out  the  Basic  Search  process. 

29.20.6 

Check 

Database 

The  mean  time  is  set  to  60  with  a  standard  deviation  of  10  seconds. 

29.20.7 

Is  Line  From 
a  Known 
Source? 

The  mean  time  is  set  to  10  with  a  standard  deviation  of  2  seconds.  70  percent  of 
the  time  a  probabilistic  decision  following  this  task  routes  the  line  to  the  task  "Is 
There  Other  Evidence?"  to  indicate  the  signal  is  not  generated  by  a  known  source. 
Alternatively,  30  percent  of  the  time  the  line  is  directed  to  the  task  "Is  Line  Likely 
from  TG?"  to  indicate  the  Operator  determined  the  signal  was  likely  generated  by 
the  Task  Group. 

29.20.9 

Is  There 

Other 

Evidence? 

The  task  mean  time  is  set  to  720  with  a  standard  deviation  of  45  seconds.  50 
percent  of  the  time  a  probabilistic  decision  following  this  task  directs  lines  to  "ID 
Source"  to  indicate  other  evidence  is  found  to  identify  the  target.  Alternatively,  50 
percent  of  the  time  the  line  is  directed  to  "ID  Unknown"  to  indicate  no  evidence  is 
found  to  enable  the  Operator  to  identify  the  target. 

29.20.16 

Is  Line 

Likely  from 
TG? 

50  percent  of  the  time  a  probabilistic  decision  following  this  task  directs  the  tag  to 
"Are  There  Related  Lines?"  to  indicate  the  line  is  generated  by  an  unknown  source 
and  not  assocated  with  the  Task  Group.  Alternatively,  50  percent  of  the  time  the 
decision  directs  the  line  to  the  task  "Search  Triple  Beam  Set"  to  indicate  the  line 
was  likely  generated  by  the  Task  Group. 

29.20.17 

Search 

Triple  Beam 
Set 

This  task  terminates  because  the  line  is  likely  from  the  Task  Group  The  variable 
named  Op#Detect  is  set  to  1  to  enable  the  Operator  to  carry  out  the  Basic  Search 
process. 

29.20.8 

Are  There 
Other 

Related 

Lines? 

A  tactical  decision  following  this  task  directs  the  line  to  either  "ID  Source"  if  there 
are  no  more  related  lines  (ie.  the  value  of  the  array  variable  named 
MoreRelatedLines  is  set  to  0)  or  to  "Search  for  Other  Lines  on  Beam"  if  there  are 
more  related  lines  left  to  be  found  (ie.  the  value  of  the  array  variable  named 
MoreRelatedLines  is  set  to  1). 
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Task 

Event  # 

Task  Title 

Task  Description 

29.20.10 

Search  for 
Other  Lines 
on  Beam 

The  task  mean  time  is  set  to  240  with  a  standard  deviation  of  75  seconds.  A  fixed 
link  directs  the  line  to  "Are  There  Any  Other  Lines  Found?" 

29.20.11 

Are  Other 
Lines 

Found? 

The  task  mean  time  is  set  to  0.5  seconds.  50  percent  of  the  time  a  probabilistic 
decision  following  this  task  directs  lines  to  the  task  "ID  Source"  to  indicate  all  lines 
related  to  this  contact  have  been  found.  Alternatively,  50  percent  of  the  time  the 
decision  directs  the  line  to  the  task  "ID  Poss"  to  indicate  all  lines  related  to  this 
contact  have  not  yet  been  found. 

29.20.12 

ID  Unknown 

The  task  mean  time  is  set  to  2  with  a  standard  deviation  of  0.4  seconds.  The  task 
terminates  and  increments  the  value  of  the  variable  named  "ID_Unknown"  by  1. 

29.20.13 

ID  Poss 

The  task  mean  time  is  set  to  2  with  a  standard  deviation  of  0.4  seconds.  The  task 
terminates  and  increments  the  value  of  the  variable  named  "ID_Poss"  by  1. 

29.20.15 

ID  Source 

The  task  mean  time  is  set  to  2  with  a  standard  deviation  of  0.4  seconds.  The  task 
terminates  and  increments  the  value  of  the  variable  named  "ID_Source"  by  1. 

Log  Process 

29.24 

Log  Contact 

The  task  mean  time  is  set  to  35  with  a  standard  deviation  of  5  seconds.  The  value 
of  the  variable  named  "loggedjines"  is  incremented  by  1  to  count  the  total  number 
of  lines  logged  during  the  simulation. 

29.25 

Are  There 
Other  Lines 
on  the  Same 
Beam? 

The  task  mean  time  is  set  to  0.5.  The  task  terminates  and  the  value  of  the  variable 
Op#Detect  is  set  to  1  to  enable  the  Operator  to  return  to  the  Basic  Search  process. 

Scenario  Events 

OpBeam 

Every  4  seconds,  this  repeating  scenario  event  calls  either  the  function  named 
"OpBeam"  if  sanitizeMode  is  equal  to  0  (ie.  Array  Sanitization  complete)  or  the 
function  named  "SanitizeBeam"  if  sanitizeMode  is  equal  to  1  (ie.  Array  Sanitization 
in  progress).  The  OpBeam  function  moves  both  Operatorl  and  Operator  to  the 
next  beam  if  there  are  no  lines  left  to  detect  on  the  display  or  on  the  current  triple 
beam  set.  Operatorl  starts  at  beam  1  and  moves  up  the  array  while  Operator 
starts  at  beam  43  and  moves  down  the  array.  The  SanitizeBeam  function  only 
moves  Operatorl  while  Operator  is  set  to  beam  0  because  it  is  assumed 

Operator  is  occupied  sanitizing  the  array. 

UpdateOps 

Every  second,  this  repeating  scenario  event  calls  a  set  of  functions  [i.e.  UpdateOpl, 
UpdateOp2,  UpdateOplTag,  and  UpdateOp2Tag]  to  update  the  current  status  of 
Operatorl  and  Operator  in  terms  of  the  current  triple  beam  set  each  Operator  is 
examining,  the  number  of  lines  on  the  current  beam,  and  the  number  of  lines  the 
Operator  is  in  process  of  examining. 
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Annex  B:  Description  of  the  function 
parameters  for  each  modelled  task 


B1.  Functions  that  are  unique  to  the  Basic  Search  process 
(see  Task  Network  29). 


Function  Name 
and  Number 

29.3  to  29.17  Examine  triple  beam  set 

Description 

The  operator  searches  the  triple  beam  display  for  evidence  of  a  sonar  signal. 

Triggering 

Conditions 

Standard  surveillance  --  select  triple  beam  set  (29.2). 

Continuous  repeating  task  (29.3  to  29.17). 

End  conditions/ 
consequences 

If  no  evidence  of  sonar  signal-operator  continues  examination  of  next  triple  beam  set 
(29.3  to  29.17). 

If  evidence  of  signal  operator  determines  if  sonar  data  is  evidence  of  signal  or  noise 
(29.18). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Gamma 

Function 

(4+#lines  A1.3) 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Discriminate:  3.7 

NA 

Signal  Recognition: 
3.7 

Continuous 

Adjustive:  2.6 
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Function  Name 
and  Number 

29.18  Decision:  is  sonar  data  evidence  of  signal  or  statistical 
noise? 

Description 

The  operator  examines  the  characteristics  of  a  single  piece  of  sonar  data  to 
determine  whether  it  is  likely  to  come  from  a  signal  source  or  is  random  statistical 
noise. 

Triggering 

Conditions 

Appearance  on  the  display  of  any  data  that  are  higher  contrast  than  the  background. 
Standard  surveillance  (29.3  to  29.17). 

End  conditions/ 
consequences 

If  noise -ignore  nois 
If  signal -select  sing 

e  and  resume  search  for  other  sonar  data  (29.21). 
le  beam  to  analyse  further  (29.20). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Lognormal 

10.0 

3 

.01 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

29.24  Log  Data 

NA 

100 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Discriminate:  3.7 

NA 

Signal  Recognition: 
3.7 

Continuous 

Adjustive:  2.6 

Function  Name 
and  Number 

29.20.1  Select  single  beam 

Description 

The  operator  selects  a  single  beam  mode  to  provide  greater  resolution  of  the  sonar 
data 

Triggering 

Conditions 

Operator  detects  sonar  data  of  interest  (29.18). 

End  conditions/ 
consequences 

The  beam  is  selected  and  displayed  and  the  operator  goes  on  to  analyse  the  sonar 
data  to  determine  if  the  sound  source  is  mechanical  (29.20.2). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

2.0 

.4 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

100 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Register/Detect: 

1.0 

NA 

Automatic:  1.0 

Discrete  Actuation: 
2.2 
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Function  Name 
and  Number 

29.20.2  Decision:  is  the  source  mechanical? 

Description 

The  operator  analyses  the  frequency  and  temporal  characteristics  of  the  sonar  data 
and  decides  whether  it  is  likely  to  be  caused  by  a  mechanical  or  non-mechanical 
agent.  The  operator  may  listen  to  the  source  to  assist  the  analysis. 

Triggering 

Conditions 

Operator  detects  sonar  data  of  interest  (29.20.1). 

End  conditions/ 
consequences 

The  operator  checks  the  log  to  see  if  the  sonar  data  have  been  entered  (29.20.3). 

NOTE:  In  reality,  the  Operator  would  reject  any  lines  that  were  not  generated  by  a 
mechanical  source.  For  the  purposes  of  this  model,  it  is  assumed  all  lines  are 
mechanical. 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

5.0 

0 

0.001 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

29.24  Log  Data 

NA 

100 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Inspect/Check:  4.0 

Discriminate 

Sound 

Characteristics: 

6.6 

Evaluation 
/Judgment:  4.6 

Continuous 
Adjustive:  2.6 

Function  Name 
and  Number 

29.20.3  Check  log 

Description 

The  operator  searches  the  paper  log  to  determine  whether  the  line  at  this  frequency 
has  already  been  logged. 

As  the  log  grows  over  time,  this  search  becomes  longer. 

Triggering 

Conditions 

Operator  determines  whether  or  not  sonar  data  as  coming  from  a  mechanical  source 
(29.20.2). 

End  conditions/ 
consequences 

Operator  decides  whether  or  not  the  line  is  already  logged  (29.20.4). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Gamma 

20.0 

5 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Read:  5.9 

NA 

Signal  Recognition: 
3.7 

Continuous 

Adjustive:  2.6 
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Function  Name 
and  Number 

29.20.4  Decision:  is  the  line  logged? 

Description 

The  operator  either  finds  or  fails  to  find  an  entry  in  the  log.  Once  the  log  is  found,  the 
decision  is  virtually  instantaneous. 

Triggering 

Conditions 

Operator  identifies  sonar  data  and  checks  the  log  to  determine  whether  the  line  at  this 
frequency  has  already  been  logged  (29.20.3). 

End  conditions/ 
consequences 

If  the  line  is  in  the  log  already  the  operator  resumes  search  on  this  triple  beam  set 
(29.20.5). 

If  the  line  is  not  in  the  log,  the  operator  enters  the  sonar  data  by  manual  entry  and 
checks  the  database  of  known  contacts  (29.20.6). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

.5 

.005 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

100% 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

NA 

NA 

Alternative 

Selection:  1.2 

NA 

Function  Name 
and  Number 

29.20.6  Check  database 

Description 

The  operator  searches  for  any  other  available  information  that  may  assist  in  identifying 
the  source  of  this  line  -  either  from  lists  of  known  sources  or  from  other  forms  of 
evidence  (e.g.  acoustics,  reports). 

Triggering 

Conditions 

The  sonar  datum  is  not  found  in  the  log  (29.20.4) 

End  conditions/ 
consequences 

Operator  checks  to  determine  whether  or  not  the  line  is  from  a  known  source  (29.20.7) 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

60.0 

10 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Read:  5.9 

Discriminate 

Sound 

Characteristics: 

6.6 

Evaluation 
/Judgment,  Several: 
6.80 

Discrete 

Actuation:  2.2 

Function  Name 
and  Number 

29.20.7  Decision:  is  line  from  known  source? 
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Description 

After  searching  sources  operator  decides  whether  there  is  evidence  to  identify  the  line 
as  coming  from  a  known  source. 

Triggering 

Conditions 

The  sonar  datum  is  not  found  in  the  log  and  the  operator  commences  search  for  other 
evidence  (29.20.6). 

End  conditions/ 
consequences 

If  positive  evidence-  the  operator  decides  that  line  is  from  a  known  source  and  the 
operator  attempts  to  determine  if  line  is  likely  from  the  Task  Group  (29.20.16). 

If  no  evidence-  the  operator  seeks  other  evidence  (29.20.9). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Gamma 

10 

2 

0.001 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

29.24:  Enter  Log 

100 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

NA 

NA 

Evaluation 
/Judgment,  Several: 
6.80 

NA 

Function  Name 
and  Number 

29.20.8  Are  there  other  related  lines? 

Description 

The  operator  checks  the  database  to  see  whether  this  possible  target  has  other  lines 
which  will  need  to  be  found  to  confirm  the  ID. 

Triggering 

Conditions 

Operator  finds  evidence  that  potentially  identifies  source  (29.20.15). 

The  operator  determines  that  the  line  is  not  from  the  Task  Group  (29.20.16). 

End  conditions/ 
consequences 

If  there  are  other  lines-  operator  searches  for  these  lines  (29.20.10). 

If  there  are  no  other  lines-operator  identifies  source  (29.20.15). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

0 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

100 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Read:  5.9 

NA 

Signal  Recognition: 

3.7 

Continuous 
Adjustive:  2.6 
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Function  Name 
and  Number 

29.20.9  Decision:  is  there  other  evidence? 

Description 

After  searching  databases  of  known  sources  operator  decides  whether  there  is  any 
other  evidence  to  identify  the  line. 

Triggering 

Conditions 

The  operator  fails  to  find  evidence  of  the  source  of  the  line  from  searching  through 
available  information  on  known  sources  (29.20.7). 

End  conditions/ 
consequences 

If  positive  evidence-  the  operator  can  proceed  to  identify  source  (29.20.15). 

If  no  evidence-  the  operator  identifies  the  source  as  Unknown  (29.20.12). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

720 

45 

0.001 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

29.20.15:  ID  Source 

100 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Read:  5.9 

Discriminate 

sound 

characteristics: 

6.6 

Evaluation 
/Judgment,  Several: 
6.80 

Continuous 
Adjustive:  2.6 

Function  Name 
and  Number 

20.20.10  Search  for  other  lines  on  beam 

Description 

The  operator  looks  for  expected  lines  at  specific  frequencies  on  the  display. 

Triggering 

Conditions 

The  operator  has  found  in  the  database  information  that  this  possible  target  has  other 
lines.  (20.20.8) 

End  conditions/ 
consequences 

If  search  finds  lines,  Operator  determines  if  other  lines  are  found  (29.20.11). 

Search  fails  to  find  lines,  Operator  determines  if  other  lines  are  found  (29.20.11). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

240 

75 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Inspect/Check:  4.0 

NA 

6.8  Evaluation 

Several  Aspects 

Continuous 
Adjustive:  2.6 
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Function  Name 
and  Number 

29.20.11  Decision:  Are  other  lines  found? 

Description 

The  operator  decides  whether  the  display  contains  the  expected  lines. 

Triggering 

Conditions 

The  operator  has  found  in  the  database  information  that  this  possible  target  has  other 
lines  (29.20.10). 

End  conditions/ 
consequences 

Search  finds  all  related  lines  -  source  can  be  identified  (29.20.15). 

Search  fails  to  find  all  related  lines-  source  can  be  ID  as  possible  (29.20.13). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

.5 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

NA 

NA 

Signal  Recognition: 

3.7 

NA 

Function  Name 
and  Number 

29.20.12  Identify  source  -  Unknown 

Description 

The  operator  identifies  the  source 

Triggering 

Conditions 

Operator  fails  to  find  any  other  evidence  that  would  ID  source  (29.20.9). 

End  conditions/ 
consequences 

Operator  logs  the  information  (29.24) 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

2 

.4 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

NA 

NA 

Evaluation 
/Judgment,  Several: 
6.80 

NA 
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Function  Name 
and  Number 

29.20.13  Identify  source  -  Possible 

Description 

The  operator  identifies  the  source. 

Triggering 

Conditions 

Operator  finds  fails  to  find  other  lines  that  would  positively  ID  source  (29.20.11). 

End  conditions/ 
consequences 

Operator  logs  the  information  (29.24). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

2 

.4 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

NA 

NA 

Evaluation 
/Judgment,  Several: 
6.80 

NA 

Function  Name 
and  Number 

29.20.15  Identify  source 

Description 

The  operator  identifies  the  source. 

Triggering 

Conditions 

Operator  finds  other  lines  that  ID  source  (29.20.11). 

Operator  finds  no  other  lines  to  ID  source  (29.20.8). 

Operator  finds  positive  evidence  to  ID  source  (29.20.9). 

End  conditions/ 
consequences 

Operator  logs  the  information  (29.24). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

2 

1 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

50% 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

NA 

NA 

Evaluation 
/Judgment,  Several: 
6.80 

NA 
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Function  Name 
and  Number 

29.20.16  Decision:  is  line  likely  from  TG? 

Description 

The  operator  determines  if  the  line  is  from  the  Task  Group. 

Triggering 

Conditions 

Operator  finds  evidence  that  line  is  from  a  known  source  (29.20.7). 

End  conditions/ 
consequences 

If  the  line  is  from  the  Task  Group,  the  operator  resumes  search  on  this  triple  beam  set 
(29.20.17). 

If  the  line  is  not  from  the  Task  Group,  the  operator  proceeds  to  determine  if  there  are 
other  related  lines  (29.20.8). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

0 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

NA 

NA 

NA 

NA 

Function  Name 
and  Number 

29.24  Log  Contact 

Description 

The  operator  writes  the  information  into  the  log  (time  will  depend  on  number  of  lines 
found). 

Triggering 

Conditions 

Contact  is  identified  Unknown  (29.20.12). 

Contact  is  identified  Possible  (29.20.13). 

Contact  is  identified  (29.20.15). 

End  conditions/ 
consequences 

Operator  searches  for  other  lines  on  the  same  beam  (29.25). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Gamma 

35 

5.0 

.30 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

29.20.15  ID  Source 

50% 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Read:  5.9 

NA 

Encoding/Decoding: 

5.3 

Symbolic 

Production:  6.5 
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B2:  Functions  that  are  unique  to  the  Auto-Sanitise  process 
(See  Task  Network  1). 


Function  Name 
and  Number 

21  Display  Data  for  Ownship/TG  Database 

Description 

Operator  actuates  quick  access  button  (QAB)  to  display  data  on  known  beam  -  this  is 
done  automatically  by  the  system. 

Triggering 

Conditions 

Beginning  of  watch  and  when  part  of  regular  sanitisation  schedule  of  every  10 
minutes. 

End  conditions/ 
consequences 

Data  are  displayed  and  Operator  determines  if  pattern  matches  lines  displayed  (22). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

2 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

NA 

NA 

NA 

NA 

Function  Name 
and  Number 

22  Does  pattern  match  lines  displayed? 

Description 

Operator  visually  checks  displayed  template  against  actual  lines  on  the  display 

Triggering 

Conditions 

First  beam  containing  line  is  for  the  current  Task  Group  member  is  displayed  (21). 

Next  beam  containing  line  is  for  the  current  Task  Group  member  is  displayed  (28). 

End  conditions/ 
consequences 

Operator  decides  whether  the  lines  displayed  match  the  template.  If  the  pattern  does 
not  match,  the  Operator  proceeds  to  Analyze  Data  (23). 

If  the  pattern  matches  the  line  displayed,  the  Operator  proceeds  to  determine  if  All 
Beams  are  Accounted  For  (24). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

10  for  25  lines 

40  for  100  lines 

2 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Discriminate:  3.7 

NA 

Evaluation  /Judgement 
(single):  4.6 

Discrete  Actuation: 
2.2 
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Function  Name 
and  Number 

23  Analyse  Data 

Description 

Operator  conducts  an  analysis  of  the  data  based  upon  other  information  that  may  be 
available. 

Triggering 

Conditions 

Template  does  not  match  lines  displayed  (22). 

End  conditions/ 
consequences 

Operator  makes  decision  on  whether  lines  are  likely  to  be  ownship/TG  (25). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Gamma 

60  for  25  Lines 

240  for  100  Lines 

12 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Locate/Align:  5.0 

Discriminate 

Sound 

Characteristics: 

6.6 

Evaluation 

/Judgment  (Several): 
6.8 

Continuous 
Adjustive:  2.6 

Function  Name 
and  Number 

24  Are  all  beams  accounted  for? 

Description 

Operator  looks  at  display  to  see  if  template  pattern  is  displayed  on  other  beams 

Triggering 

Conditions 

Line  pattern  matches  template  (22). 

Analysis  complete  on  current  beam  (27). 

End  conditions/ 
consequences 

If  more  data  exists  on  other  beams,  operator  iteratively  repeats  pattern 
matching/analysis  process  for  other  beams  (22). 

If  no  more  data  is  found  on  other  beams,  the  operator  proceeds  to  next  TG  member 
(26). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

2 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Inspect/Check:  4.0 

Detect/Register 
Sound:  1.0 

Evaluation 

/Judgement  (Single): 
4.6 

Discrete  Actuation: 
2.2 
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Function  Name 
and  Number 

25  Are  Displayed  Lines  from  Ownship/TG? 

Description 

Based  upon  the  prior  analysis  the  operator  decides  on  whether  the  lines  are  from 
ownship/TG  or  not. 

Triggering 

Conditions 

Analysis  of  displayed  lines  completed  (23). 

End  conditions/ 
consequences 

Operator  decides  source  of  lines  is  not  attributed  to  Ownship/TG  (27). 

Operator  decides  source  of  lines  is  attributed  to  Ownship/TG  (28). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

2 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

NA 

NA 

Automatic:  1.0 

NA 

Function  Name 
and  Number 

26  Are  all  TG  accounted  for? 

Description 

Operator  determines  if  santisation  completed  for  all  ownship/TG.  Simple  QAB 
continues  process  for  next  TG  member. 

Triggering 

Conditions 

All  Beams  are  accounted  for  TG/Ownship  (24). 

All  Beams  are  accounted  for  and  analysis  complete  on  current  ownship/TG  (28). 

End  conditions/ 
consequences 

If  completed  operator  resumes  standard  search/identification  process  (30). 

If  not  completed,  operator  iterates  through  remaining  TG  (15). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

2 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Inspect/Check:  4.0 

NA 

Evaluation 
/Judgement:  4.6 

2.2  Discrete 
Actuation 
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Function  Name 
and  Number 

27  Update  Database 

Description 

If  the  lines  are  from  ownship/TG,  the  database  is  updated  to  reflect  the  current  data. 

This  process  would  be  accomplished  through  clicking  on  lines,  QAB  action  and  menu 
selection. 

Triggering 

Conditions 

Lines  are  identified  as  from  Ownship/TG  (25). 

End  conditions/ 
consequences 

Database  is  updated  to  reflect  current  data  (24). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

30  for  25  Lines 

120  for  100  Lines 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Read:  5.9 

NA 

Automatic:  1.0 

Symbolic 

Production:  6.5 

Function  Name 
and  Number 

28  Display  Data  for  Ownship/TG 

Description 

Operator  enters  updated  information  into  database 

Triggering 

Conditions 

Operator  decides  source  of  lines  is  attributed  to  Ownship/TG  (28). 

End  conditions/ 
consequences 

More  Beams  have  yet  to  be  examined  for  the  current  Task  Group  member.  The  next 
beam  containing  line  is  for  the  current  Task  Group  member  is  displayed  (22). 

All  Beams  are  accounted  for  and  analysis  complete  on  current  Ownship/TG  (26). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

0 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

NA 

NA 

NA 

NA 
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B3.  Functions  that  are  unique  to  the  Manual  Sanitise  process 
(see  Task  Network  1). 


Function  Name 
and  Number 

9  Select  Beam 

Description 

Operator  selects  the  next  beam  to  examine. 

Triggering 

Conditions 

Operator  selects  next  beam  to  search  for  the  current  Task  Group  member  (Task  4  to 

8). 

End  conditions/ 
consequences 

Operator  searches  beam  (10). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

2 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Register/Detect: 

1.0 

NA 

Alternative  Selection: 
1.2 

Discrete  Actuation: 
2.2 

Function  Name 
and  Number 

10  Search  Beam  for  All  Lines 

Description 

Operator  searches  the  current  beam  for  all  TG/Ownship  lines. 

Triggering 

Conditions 

Operator  selects  the  next  beam  for  the  current  Task  Group  member  (9). 

End  conditions/ 
consequences 

Operator  logs  all  possible  contacts  on  the  current  beam  (11). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

2 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Register/Detect: 

1.0 

NA 

Automatic:  1.0 

NA 
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Function  Name 
and  Number 

11  Found  All  Lines? 

Description 

Operator  searches  beam  for  all  lines. 

Triggering 

Conditions 

Operator  searches  beam  (10). 

End  conditions/ 
consequences 

Log  lines  found  on  beam  (11). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

2 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Register/Detect: 

1.0 

NA 

Automatic  1.0 

NA 

Function  Name 
and  Number 

12  Log  Lines 

Description 

Log  is  updated  to  reflect  the  current  data.  This  process  is  completed  manually. 

Triggering 

Conditions 

All  lines  are  found  on  the  current  beam  (11). 

End  conditions/ 
consequences 

The  Operator  determines  whether  there  are  more  beams  to  search  for  the  current 

Task  Group  member  (13). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

30  for  25  Lines 

60  for  100  Lines 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Read:  5.9 

NA 

Automatic:  1.0 

Symbolic 

Production:  6.5 
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Function  Name 
and  Number 

13  More  Beams  to  Search? 

Description 

Operator  determines  whether  or  not  all  beams  have  been  searched. 

Triggering 

Conditions 

All  lines  are  logged  on  the  current  beam  (12). 

End  conditions/ 
consequences 

If  more  remaining  beams  exist  for  the  current  Task  Group  member,  the  Operator 
selects  the  next  beam  (9). 

If  there  are  no  more  remaining  beams  to  search  for  the  current  Task  Group  member, 
the  Operator  determines  if  all  Task  Group  members  have  been  identified  (14). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

2 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Register/Detect: 

1.0 

NA 

Automatic:  1.0 

Discrete  Actuation: 
2.2 

Function  Name 
and  Number 

14  All  TG  Done? 

Description 

Operator  determines  whether  or  not  all  Task  Group  members  have  been  identified. 

Triggering 

Conditions 

End  conditions/ 
consequences 

When  all  Task  Group  members  have  been  identified,  the  Operator  continues  with  the 
Basic  Search  process  (30). 

If  more  Task  Group  members  remain  to  be  identified,  the  Operator  selects  the  next 

Task  Group  member  (3). 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

2 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

Register/Detect 

1.0 

NA 

Automatic  1.0 

Discrete  Actuation 
2.2 
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B4.  Functions  that  are  common  between  the  Automated  and  Manual 
Sanitise  Process  (see  Task  Network  1). 


Function  Name 
and  Number 

2.  Manual  or  Auto 

Description 

This  task  is  performed  by  the  operator  at  the  start  of  the  watch 

Triggering 

Conditions 

Start  of  simulation  (1). 

Watch  handover  is  set  to  occur  at  the  start  of  the  simulation  and  every  600  seconds 
after  the  array  has  been  sanitized  (18). 

End  conditions/ 
consequences 

Operator  makes  a  decision  to  manually  (3)  or  automatically  (15)  sanitise  the  array. 

Properties 

Distribution 

Mean  Time  (sec) 

Std.  Deviation 

Prob  of  failure 

Normal 

0 

0 

0 

Consequences  of 
failure 

Task  affected 

Percent  Time 
Degradation 

Percent  Failure 
Degradation 

NA 

NA 

NA 

Workload  Rating 

Visual 

Auditory 

Cognitive 

Psychomotor 

NA 

NA 

NA 

NA 
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Annex  C:  Values  selected  for  the 
Environmental  Model 


Values  that  are  different  from  the  default  model  are  shown  with  a  gray  background. 


Variable 

Acceptable  Values 

Units 

Value 

Default 

Initial 

Value 

Physical 

Ambient_Noise 

0  to  200 

dBA 

75 

3 

Contamination_Level 

None,  High,  Medium,  Low 

NoneHiMedLow 

None 

None 

Contamination_Type 

None,  Biological,  Nuclear, 

Chemical 

Contamination_Type 

None 

None 

Digability 

NA,  Very_Hard,  Moderately_Hard, 
Firm,  Soft,  Very_Soft 

Digability 

NA 

NA 

Dry_Bulb_Temperat 

ure 

-100  to  +100 

Degrees_Celsius 

20 

30 

Env_Type 

Air,  Water 

EnvType 

Air 

Air 

Footing 

NA,  Black_Top,  Dirt_Road, 
Light_Brush,  Packed_Snow, 
Heavy_Brush,  Swampy_Bog, 
Loose_Sand,  Soft_Snow 

Footing_Type 

NA 

NA 

Humidity 

0  to  100 

Percent 

20 

20 

Illumination 

Noon_Day,  Summer_Sunlight, 
Average_Clear_Day, 
Average_Overcast_Day,  Dusk, 
Moonlight,  Starlight,  Redlighting 

lllum_Type 

dusk 

Noon_ 

Day 

Pressure 

0-10,000,000 

Pascals 

101,325 

101,325 

Sea_State 

None,  Slight,  Moderate,  Severe 

Motion 

Moderate 

None 

Temperature 

-100  to  +100 

Degrees_Celsius 

15 

100 

Terrain 

None,  Rock,  Forest,  Desert 

Terrain_Type 

None 

None 

Te  r  rai  n_D  i  recti  o  n 

0  to  <360 

Degrees 

0 

0 

Terrain_Slope 

-90  to  90 

Degrees 

0 

0 

Thermal_Radiation 

0-10,000,000 

Watts/m2 

0 

0 

Time_Of_Day 

0  to  2400 

Hours 

600 

600 

Turbulence 

None,  Slight,  Moderate,  Severe 

Motion 

None 

None 

Weather 

Clear,  Heavy_Rain,  Medium_Rain, 
Heavy_Snow,  Medium_Snow,  Mist, 
Fog,  Heavy_Overcast, 

Wx_Type 

Clear 

Clear 
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Variable 

Acceptable  Values 

Units 

Value 

Default 

Initial 

Value 

Medium_Overcast 

Wind_Direction 

0  to  360 

Degrees 

0 

0 

Wind_Speed 

0  to  500 

Metres/sec 

0 

0 

Wind_Strength 

Oto  12 

Beaufort 

0 

2 

Mission 

Adequacy_Of_Proce 

dures 

NA,  Good,  Moderate,  Poor 

GoodModPoor 

Good 

Good 

Communications_De 

nsity 

High,  Medium,  Low 

HiMedLow 

Medium 

Medium 

Intelligence 

Good,  Moderate,  Incomplete,  None 

Intelligence 

Good 

Good 

Platform_Reliability 

0  to  100 

Percent 

95 

95 

Surveillance_Reliabil 

ity 

0  to  100 

Percent 

75 

75 

Time_Stress 

0  to  100 

Percent 

50 

0 

Weapons_Reliability 

0  to  100 

Percent 

75 

75 

Crew 

Clarity_of_Role 

Good,  Average,  Poor 

GoodAvgPoor 

Good 

Good 

Cooperation 

NA,  Good,  Moderate,  Poor 

GoodModPoor 

Good 

Good 

Leadership_Style 

NA,  Good,  Moderate,  Poor 

GoodModPoor 

Good 

Good 

Supervision 

Yes,  No 

Yes/No 

Yes 

Yes 

Team_Experience 

0  to  50 

Years 

1 

1 

Team_Morale 

None,  High,  Medium,  Low 

NoneHiMedLow 

Medium 

Medium 

Team_Training 

None,  High,  Medium,  Low 

NoneHiMedLow 

Medium 

Medium 

Threat 

Target_Bearing 

0  to  360 

Degrees 

0 

0 

Target_Elevation 

0  to  50,000 

Metres 

0 

0 

Target_Location 

NA,  Land,  Air,  Sea 

Location 

Sea 

NA 

Target_Obscuration 

Visible,  Partially_Visible,  Invisible 

Obscuration 

Partially_V 

isible 

Visible 

Target_Range 

0  to  100 

Kilometres 

25 

0 

Threat_Severity 

None,  High,  Medium,  Low 

NoneHiMedLow 

High 

None 

Target_Signature 

None,  High,  Medium,  Low 

NoneHiMedLow 

Low 

None 

Target_Speed 

Oto  2,000 

Metres/sec 

3 

0 

Target_Value 

None,  High,  Medium,  Low 

NoneHiMedLow 

High 

None 
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Annex  D.  The  Crew  Model 


Trait  Variables 

Acceptable  Values 

Units 

Value 

Default 

Initial  Value 

Agility 

None,  High,  Medium,  Low 

NoneHiMe 

dLow 

Medium 

Medium 

Auditory_Acuity 

0  to  100 

dB 

40 

0 

Cognitive_Ability 

None,  High,  Medium,  Low 

NoneHiMe 

dLow 

Med 

Low 

Fitness 

0  to  500 

Watts 

250 

250 

Mental_Capacity 

0  to  100 

Percent 

75 

50 

Motion_Sickness 

None,  High,  Medium,  Low 

NoneHiMe 

dLow 

None 

None 

Personality 

Non_Neurotic_lntrovert, 

Neuroticjntrovert, 

Non_Neurotic_Extrovert, 

Neurotic_Extrovert 

Personality 

Non_Neuroti 

c_Extrovert 

Non_Neuroti 

c_Extrovert 

Physical_Skill_Lev 

el 

None,  High,  Medium,  Low 

None 

Medium 

Medium 

Ti  me_S  i  n  ce_T  rai  n  i 

ng 

0  to  48 

Months 

6 

6 

Visual_Acuity 

1  to  10 

None 

10 

5 

YearsJ  n_Position 

0  to  50 

Years 

2 

2 

State  Variables 

Acceptable  Values 

Units 

Value 

Default 

Initial  Value 

Auditory_Signal_L 

ocalisation 

0  to  3600 

Mils 

0 

0 

Clothing 

0  to  100 

Clo's 

10 

10 

Comfort 

None,  High,  Medium,  Low 

NoneHiMe 

dLow 

Medium 

Medium 

Confidence_in_Sys 

tem 

High,  Medium,  Low 

HiMedLow 

High 

Low 

Encumbrance 

None,  High,  Medium,  Low 

NoneHiMe 

dLow 

None 

Low 

Fear 

None,  High,  Medium,  Low 

NoneHiMe 

dLow 

Low 

None 

Field_of_View 

0  to  3200 

Mils 

600 

600 

Plunger 

None,  High,  Medium,  Low 

NoneHiMe 

dLow 

Low 

Low 
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Trait  Variables 

Acceptable  Values 

Units 

Value 

Default 

Initial  Value 

Manual_Dexterity 

High,  Medium,  Low 

HiMedLow 

Medium 

Medium 

Mental_Alertness 

High,  Medium,  Low 

HiMedLow 

Medium 

Medium 

Morale 

High,  Medium,  Low 

HiMedLow 

Medium 

Medium 

Motivation 

High,  Medium,  Low 

HiMedLow 

Medium 

Medium 

NBC_Kit 

None,  Nuclear,  Chemical,  Biological 

Contamina 

tion_Type 

None 

Biological 

Perceived_Safety 

None,  High,  Medium,  Low 

NoneHiMe 

dLow 

Medium 

Medium 

Perceived_Target_ 

Value 

None,  High,  Medium,  Low 

NoneHiMe 

dLow 

Hi 

None 

Perceived_Threat 

None,  High,  Medium,  Low 

NoneHiMe 

dLow 

High 

None 

Physical_Fatigue 

Oto  10 

None 

5 

5 

Physical_Load 

0  to  100 

Kilograms 

0 

0 

Psychological_Stre 

ss 

None,  High,  Medium,  Low 

NoneHiMe 

dLow 

Med 

Low 

Situation_Awarene 

ss 

Good,  Average,  Poor 

GoodAvgP 

oor 

Average 

Average 

Thermal_Stress 

0  to  100 

Degrees_ 

Celsius 

15 

30 

Thirst 

None,  High,  Medium,  Low 

NoneHiMe 

dLow 

Low 

Low 

Time_Since_Ate 

0  to  100 

Hours 

6 

2 

Time_Since_Drank 

0  to  100 

Hours 

3 

4 

Time_Since_Slept 

0  to  100 

Hours 

7 

4 
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